私はかつてMVVM / WPFプロジェクトを開始しましたが、最終的にはビルドおよびデプロイされ、そのためにCaliburn.MicroMVVMフレームワークを数多く研究しました。実際のところ、私はそのためにCaliburn.Microを使用しないことになり、いくつかのMVVMの概念を自分で実装することになりました（具体的には、ViewModelBaseとRoutedCommandクラス）。
これで、同じ方針に沿ったやや大きなプロジェクトに割り当てられました："シングルユーザーリッチクライアントオフラインデスクトップアプリケーション"と言うと、Caliburn.Microを使用することにしました。そして、それが私の"問題"の始まりです。
この有名なブログ投稿のタイトルには" MVVMを使用している場合は、フレームワーク"が必要：
"フレームワークなしでMVVMのようなことをしようとすると膨大な量の作業になります。大量の重複コード、車輪の再発明、人々の考え方の違いを再訓練する。
少なくとも重複するコードを回避し、うまくいけば車輪の再発明をする必要がないフレームワーク–人々の再訓練に集中できるようにします。再トレーニングの部分は一般的に避けられませんが、フレームワークは配管コードと構造を提供し、プロセスを容易にします。 "
最初に読むことに同意しますが、Caliburn.Micro（CM）での実際の経験は 私の実際のアプリケーションでは、無知で方向感覚が失われています。つまり、フレームワークはプロセスをまったく簡単にしませんでした。まったく逆です。RobEisenbergによって提供された、かなり（あまりにも）非公式なドキュメントで繰り返される例を読み、複雑な提供されたサンプルから使用パターンを推測しようとしました。そして、副作用に基づいて 機能するように設計されているように見える、完全に間接的なクラスとインターフェースの関係は、経験豊富な天才でない限り、人間的に不可能に思えます（暴言を申し訳ありませんが、ご存知だと思います）
言うまでもなく、上記の些細なシナリオにはIoCコンテナが関係しているようです。これは私が一度も使用したことがなく、私が持っていないかもしれない問題を解決する。私は自分の問題とアプリケーションドメインについて考える代わりに、それらのことを学ぶためにプロジェクト時間をもっと費やす気がしません。バナナが欲しかったのですが、CMがバナナのバスケットを持ったゴリラ（IoC）をくれました。
今、私は自家製のMVVMフレームワークに戻ることを検討しています-ほんの一握りのMVVMで構成されています-私が実際に実装したい特定のクラス-ここで何かを失ったり、単に"間違った方法で何かをしている場合に備えて少なくともCMにチャンスを与えたいと思います"まったくの経験不足と無知から。したがって、問題は次のとおりです。
"フレームワークによって物事がより簡単かつ自然になるというコンセンサスが広まっています"ですが、まったく逆のことが起こった場合、これはフレームワークを使用すべきではないことを意味しますか、それとも間違った方法で学習しようとしていることを意味しますか？そもそもフレームワークを使うべきではないという手がかり？または、CMを使用して単純なMVVM開発を行う方法を理解するための"正しい"方法はありますか？
コメント
回答
CaliburnMicroとMVVMLightを試しましたそして、Caliburnを使用するとき、私はあなたが感じるものを本当に感じます。Name= " PropertyName "古いText = " {Bind PropertyName} "の代わりに、しかし結局、Caliburnはこの魔法のことをするために船外に出ます。何かがうまくいかないとき、デバッグするのは本当に難しく、事態を悪化させるには、1つのことをする方法がたくさんあります。
対照的に、MVVMLightは本当に薄いです。これを使用すると、MVVMフレームワークとほぼ100％似ており、いくつかの機能が散りばめられていることに気付くでしょう。
これでは質問に答えられないことはわかっています"フレームワークを使用しない方法"ですが、率直に言って、そのルートを使用することはお勧めできません。最初に単純なフレームワークを使用するのではなく、フル機能のフレームワークを使用したため、あなたはただ迷子になっていると思います。
コメント
- では、そう思いますか？少なくとも、MVVMLightを"の"の一種の"として使用する必要があります。 > Caliburn.Microの見当識障害"？そうだとしたら、きっと見ていきます。
- @heltonbiker間違いなく、やってみてください。少なくともMVVMフレームワークの足がかりが得られるはずです。
- あまりにも多くの魔法が起こっていることに同意します。私が推測するcとアセンブリの背景から来ています。 E何かが'機能しないのは、バックグラウンドの魔法のために機能することを見つけるためだけです。デバッグが不可能であり、パフォーマンスの問題がある場合は、簡単に解決できないことがよくあります。
回答
MVVMとは何かを理解することが重要です。再実装（JPEGファイルの解析または特定のSQLデータベースサーバーへの接続）する必要のない機能の共有ビットではなく、パターン-選択方法のパターンです。豊富なGUIを実装します。したがって、パターンの実装が単純で単純であれば、フレームワークではなく、パターンを使用することに恥を感じる必要はないと思います。
確かに、フレームワークとしてのパターンのアイデア全体には、行き過ぎた。何かがパターンであるためには、それはソリューションのクラスの一般的な形でなければなりません。そのため、パターンを使用するシステムに合わせてパターンを調整する必要があり、万能のパターンを使用しようとすると、それを行うことはできません。パターンの実装をアプリケーション設計者に任せて、アーキテクチャではなく機能をカプセル化するライブラリを提供する方がはるかに建設的です。
コメント
- 追加つまり、Microsoftが提供するMVVM（すぐに使用できるWPF）は非常に不足しています。自分自身をベテランの開発者だと思っている（そして当然のことながら）プログラマーにとってさえ、非常にイライラします。マジックストリング、実行時のあいまいな例外、ラジオボタンのグループを列挙型にバインドするなどの最も基本的なものは、 stackoverflow.com/q/397556/168719 のようになります-何フレームワークはできますか？彼らは、このレベルの複雑さを反映するか、それに対して非常に厚い抽象化を提供しようとする必要があります。
- @KonradMorawskiWPF自体はMVVMではありません。 WPFを使用してコードビハインドを実行できますが、'はMVVMではありません。したがって、WPFとMVVMを実行する場合は、' MVVMフレームワークを使用するか、自分で実装する必要があります。
- @Andyもちろんですが、' WPFはMMVMを意図していると言っても過言ではありません。'は、WPFに組み込まれているMVVM機能を指します。まだコードビハインドを実行できることはわかっています
- @KonradMorawski MVVMでWPFを使用でき、その可能性を念頭に置いて構築されていますが、WPFに組み込まれているMVVM固有の機能はありません。 WinFormsでMVPを使用できるのと同じように、WinFormsはそのパターンを使用するために特別に何も提供していません。それはあなた次第です。
- @Andy多分私たちは'議論しています今の定義。つまり、MVVMを可能にするすべての" glue "がすでに存在します-XAMLのデータバインディング、
DataContextなど
回答
WPFを初めて使用したのは、Caliburnを使用したことです。マイクロなので、これはおそらくほとんどの開発者とはかなり異なります。 WPFとCaliburn.Microの両方が、WinFormsからの非常に急な学習曲線であることがわかりましたが、両方をある程度経験した後、ペアとして使用するのが楽しいと感じました。現在、Caliburn.Microが使用されていない別の組織で働いているので、重複する配管コードがたくさんあり、コードベースが非常に肥大化し、不必要に複雑になっていることがわかります。
いくつかの落とし穴があることに間違いなく同意します。 Caliburn.Microを使用すると、デバッグが複雑になる可能性がありますが、一度経験すると、再び苦痛になる可能性ははるかに低くなります。開発速度の向上、よりクリーンでスリムなコード、そしてより良いMVVMを促進する全体的なフレームワークは、私にとってそれ以上の価値があります。
Caliburn.Microは、ストックWPFも無効にしません。その上に構築されるだけです。つまり、必要に応じてWPF機能を使用し、必要に応じてCaliburnを数個使用できます。これは、TypeScriptとJavaScriptが私の頭の中で共存する方法に似ています。
機会があれば、将来取り組む新しいWPFプロジェクトでCaliburn.Microを使用するのが最も確実です。
コメント
- ご回答ありがとうございます。 2年後、依存性注入コンテナの概念を理解した後、これらのフレームワークを"受け入れるのがはるかに簡単であることがわかりました。優れたMarkSeeman ' s " DI in .NET "本。
回答
Caliburn.Microに不満を感じてここに到着した人は、次のフレームワークをご覧ください。スタイレット
これはCaliburn.Microに触発されていますが、何が起こっているのかについて混乱させる多くの魔法を取り除く点が異なります。さらに、ドキュメントは、技術的な専門用語を通り抜けたいとは思わずに、はるかにわかりやすい言語で書かれています。初心者にははるかに優れています。
また、StyletはViewModel-Firstアプローチを採用しています。 Caliburn.Microおよび他の多くのフレームワークは、いくつかの厄介な問題を伴うビューファーストアプローチを採用しています。 SOLIDの原則とパターン化されたコードがすでに非常に得意な場合は、ビューではなくロジックがシステムを駆動する必要があるという観点から、ViewModel-Firstアプローチの方が自然であることがわかるでしょう。
EventAggregatorを使用し、メッセージングにはNotificationObjectを使用するのが好きです。 ViewModelBase、およびコマンド用のMVVM Light ' sRelayCommand。重要なことは、フレームワークが解決しようとしている問題を特定し、それらのソリューションのみを使用することです。 'フレームワークライブラリ全体を使用せざるを得ない'とは思わないでください。RelayCommandの実装が見つかりませんでした（" ICommandプロパティにバインドするのではなく、慣例によりメソッドに直接バインド"します。RelayCommandを取得します。