特定のMVVMアプリケーションでフレームワーク(Caliburn.Microなど)を使用しないことを選択する方法は?


28

私はかつてMVVM / WPFプロジェクトを開始しました。このプロジェクトは最終的に構築および展開され、そのためにCaliburn.Micro MVVMフレームワークの多くを学びました。実際のところ、私はそのためにCaliburn.Microを使用せ、自分でMVVMの概念をいくつか実装しました(具体的には、ViewModelBaseRoutedCommandクラスのみ)。

今、私は同じ行に沿ってやや大きなプロジェクトに割り当てられました:「シングルユーザーリッチクライアントオフラインデスクトップアプリケーション」、と言うことで、私はCaliburn.Microを使用することにしました。それが私の「問題」の始まりです。

私はこの有名なブログ記事で、タイトルに「MVVMを使用している場合、フレームワークが必要」と書かれています。

「フレームワークなしでMVVMのようなことをしようとすると、膨大な作業が必要になります。大量のコードを複製し、車輪を再発明し、考え方を変えるように人々を再訓練します

少なくともフレームワークを使用すれば、コードの重複を避け、できれば車輪を再発明する必要がなく、人々の再訓練に集中できるようになります。通常、再トレーニングの部分は避けられませんが、フレームワークは配管コードと構造を提供し、プロセスを容易にします。

最初に読むことに同意しますが、実際のアプリケーションでのCaliburn.Micro(CM)での実際の経験は、無知で見当識障害です。つまり、フレームワークはプロセスをまったく簡単にしませんでした。まったく逆です。むしろ、(あまりにも)非公式マニュアルにロブ・アイゼンバーグが提供する絶えず繰り返し実施例を読むこと、そして物事が動作するように設計されているように見える畳み込まれて、サンプル、およびその全く間接的なクラスとインタフェースの関係から、使用パターンを推測しようとしているベースの上を副作用は、あなたがベテランの天才でない限り、人間的には不可能だと思われます(暴言はごめんなさい。

任意の上記の些細なシナリオことは言うまでもありません私が働いたことがない何かである、IoCコンテナを伴うように思われ、どのように見える私も持っていないかもしれない問題を解決。私の問題やアプリケーションの領域について考えるのではなく、これらのことを学ぶためにプロジェクトにもっと時間を費やすつもりはありません。バナナが欲しかったのですが、CMはバナナのバスケットを持ったゴリラ(IoC)をくれました。

私が実際に実装したい少数のMVVM固有のクラスのみで構成される自作MVVMフレームワークに戻ることを検討しているので、ここで何かを失った場合に備えて、少なくともCMにチャンスを与えたいと思います。まったくの未経験と無知から「間違った方法で」物事を行うだけです。そして質問は次のとおりです。

「フレームワークは物事をより簡単に、より自然にする」というコンセンサスが広まっていますが、もし私がまったく逆になっているのであれば、フレームワークを使うべきではないということですか、それとも間違った方法で学習しようとしていますか?そもそもフレームワークを使用するべきではないという手がかりはありますか?または、単純なMVVM開発でCMを使用する方法を理解するための「正しい」方法はありますか


1
個人的には、各フレームワークから特定の動作に使用するアイテムを選択し、残りは無視します。たとえばEventAggregator、メッセージングにはMicrosoft PRISMを、コマンドにNotificationObjectはViewModelBaseを、MVVM Light を使用するのが好きRelayCommandです。重要なことは、フレームワークがあなたのために解決しようとしている問題を特定し、それらのソリューションのみを使用することです。フレームワークライブラリ全体の使用を余儀なくされていると感じないでください。
レイチェル

@Rachel IはこのアプローチをCaliburn.Microで使用する予定でしたが、RelayCommand実装を見つけることができませんでした(ICommandプロパティにバインドするのではなく、慣例によりメソッドに直接「バインド」するため)。
heltonbiker

Caliburnフレームワークを使用したことがないのは、ViewがModel / ViewModelレイヤーにどれほど密接に結びついているかが気に入らなかったためです。あなたの場合、RelayCommandCaliburn Microで使用されているライブラリが機能しない場合、別のライブラリのを使用できなかった理由はわかりません。
レイチェル

「[caliburn]がビューをMVMレイヤーにどれだけ近づけるか」に関する@Rachel、正確にはどういう意味ですか?これらのレイヤーをより優れた、より多くのMVVMの方法で結ぶ「非キャリブレーション」方法は何でしょうか?(私は現在知りませんので、心からお願いします)。
heltonbiker

正直なところ、Caliburn Microを使用したことがないので、フレームワークの評価が悪いと感じています。Viewが最初に作成され、コードビハインドオブジェクトを決定する責任があるという印象を得たことを思い出します。これは、View-First開発が好きではないので好きではない側面の1つです。もう1つは、XAMLコンポーネントに名前を付ける方法に依存する自動バインディングです。これは、UIをビジネスレイヤーに過度に結び付けていると思ったためです。フレームワークについては良いことを聞いたことがありますが、私の意見だけではそれを避けることを提案しません。自分で試してみて、気に入ったかどうかを確認してください:)
レイチェル

回答:


16

私はCaliburnMicroとMVVMLightを試しましたが、Caliburnを使用するとき、私は本当にあなたが感じるものを感じます。 Caliburnはこの魔法のようなことを行うために船外に出て行きます。何かがうまくいかないときはデバッグが非常に難しく、事態を悪化させるために彼らは一つのことをする多くの方法を持っています。

しかし、MVVMLightを使用するときは薄いので、使用すると、MVVMフレームワークのようにほぼ100%の機能を備えていることに気づくでしょう。

私はこれがあなたの質問「フレームワークを使用しない方法」に答えないことを知っていますが、率直に言って、間違っているのでそのルートに行くことはお勧めできません。最初に。


では、少なくともMVVMLightを「Caliburn.Microの見当識障害」からのある種の「治療」として使用しようとすべきだと思いますか?もしそうなら私は確かに見てみます。
heltonbiker

@heltonbiker間違いなく、やってみてください。少なくともMVVMフレームワークの足がかりを得るには、はるかに簡単です。
キリエ

私はあまりにも多くの魔法が進行していることに同意します。ACとアセンブリのバックグラウンドから来ていると思います。バックグラウンドでの魔法が原因で何かを見つけるだけでは機能しません。デバッグすることは不可能であり、パフォーマンスの問題が発生した場合、たいていの場合、簡単に対処できません。
ロール

10

MVVMとは何かを理解することが重要です。それはあなたが(JPEGファイルを解析または指定されたSQLデータベースサーバーへの接続)を再実装する必要がないこと、それは機能のいくつかの共有ビットではないパターン 1は、豊富なGUIを実装することもできますどのようにするためのパターン--a。したがって、パターンの実装が単純で簡単な場合、フレームワークではなくパターンを使用することに恥を感じる必要はないと思います。

実際、私はフレームワークとしてのパターンのアイデア全体が行き過ぎていると信じています。パターンになるには、ソリューションのクラスの一般的な形状でなければなりません。そのため、パターンを使用するシステムに合わせてパターンを調整する必要があり、万能パターンを使用しようとすると、パターンを調整できないことが予想されます。パターンの実装をアプリケーション設計者に任せ、アーキテクチャではなく機能をカプセル化するライブラリを提供する方がはるかに建設的です。


2
それに加えて、Microsoftが提供するMVVM(すぐに使用できるWPF)は非常に不足しています。自分自身を(そして当然のことながら)熟練した開発者と考えるプログラマーにとっても非常にイライラします。マジックストリング、実行時の不明瞭な例外、ラジオボタンのグループを列挙にバインドするなどの最も基本的なものは、stackoverflow.com / q / 397556/168719のように見えます-フレームワークは何ができますか?彼らは、このレベルの複雑さを反映するか、それ以上の非常に厚い抽象化を提供しようとする必要があります
Konrad Morawski

2
@KonradMorawski WPF自体はMVVMではありません。WPFでコードビハインドを実行できますが、それはMVVMではありません。したがって、WPFとMVVMを実行する場合は、MVVMフレームワークを使用するか、自分で実装する必要があります。
アンディ

1
@Andyはもちろんですが、WPFはMMVMを対象としています。WPFに組み込まれているMVVM機能について言及しています。あなたはまだコードビハインドを行うことができることを知っている
コンラッドMorawski

@KonradMorawski MVVMでWPFを使用することができ、その可能性を念頭に置いて構築されましたが、WPFにはMVVM固有の機能は組み込まれていません。WinFormsでMVPを使用できるように、WinFormsにはそのパターンを使用するための特別なものは何もありません。
アンディ

3
@Andyは今、定義について議論しています。XAMLでのデータバインディング、 -私は何を意味するMVVMが可能になり、すべての「のり」がすでにあるということであるDataContextなど
コンラートMorawski

7

WPFでの最初の経験はCaliburn.Microを使用していたため、これはおそらくほとんどの開発者とはかなり異なります。私はWPFとCaliburn.Microの両方がWinFormsから得られる非常に急な学習曲線であることがわかりましたが、両方の経験を積んだ後、それらをペアとして使用する喜びを感じました。現在、Caliburn.Microが使用されていない別の組織で働いていますが、重複した配管コードが大量にあり、コードベースが非常に肥大化し、不必要に複雑になっています。

Caliburn.Microには、デバッグを複雑にする可能性のある落とし穴があることに間違いなく同意しますが、一度経験すると、再び痛みを感じる可能性ははるかに低くなります。開発速度の向上、よりクリーンで無駄のないコード、MVVMの向上を促進する全体的なフレームワークは、私にとって価値があります。

また、Caliburn.MicroはストックWPFを無効にしません。その上に構築されるだけです。つまり、必要に応じてWPF機能を使用し、必要に応じてCaliburnを使用できます。これは、TypeScriptとJavaScriptが私の心で共存する方法に似ています。

機会があれば、私が将来取り組んでいる新しいWPFプロジェクトでCaliburn.Microを使用するのは間違いありません。


3
ご回答有難うございます。2年後、優れたMark Seemanの「DI in .NET」の本から学んだDependency Injection Containersの概念を理解した後、これらのフレームワークを「受け入れる」ことがはるかに簡単になりました。
heltonbiker

1

Caliburn.Microの不満からここに到着した人は、このフレームワークをご覧ください: Stylet

Caliburn.Microにインスパイアされていますが、何が起こっているのかを混乱させる多くの魔法が取り除かれている点が異なります。さらに、ドキュメントは、専門用語を読み進めることを想定せずに、はるかにわかりやすい言語で書かれています。初心者にとってはずっと良い。

また、StyletはViewModel-Firstアプローチを採用しています。Caliburn.Microおよび他の多くのフレームワークは、いくつかの厄介な問題を伴うView-Firstアプローチを採用しています。すでにSOLIDの原則とパターン化されたコードが得意であれば、ViewModel-Firstアプローチがより自然であることがわかります。これは、ビューではなく、ロジックがシステムを駆動するという観点をとるからです。

弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.