MVVMは無意味ですか？[閉まっている]

Question 1

正統なMVVM実装は無意味ですか？新しいアプリケーションを作成していて、WindowsフォームとWPFを検討しました。WPFを選択した理由は、将来性があり、柔軟性が高いためです。コードが少なく、XAMLを使用してUIに大幅な変更を加えるのが簡単です。

WPFの選択は明白であるため、ブレンド性、分離の懸念、および単体テスト性を提供するため、アプリケーションアーキテクチャとしてMVVMを使用することで、最大限に活用できると考えました。理論的には、UIプログラミングの聖杯のように美しく見えます。この短い冒険。しかし、本当の頭痛になっています。実際には、予想通り、ある問題を別の問題と交換していることがわかりました。私は、正しい結果を得て、より良いプログラマーになるために正しい方法で物事をやりたいという点で、強迫的なプログラマーになる傾向があります。MVVMパターンは、生産性に関する私のテストを失敗させ、大きな厄介なハックに変わりました！

明確な例は、モーダルダイアログボックスのサポートを追加することです。正しい方法は、ダイアログボックスを表示してビューモデルに関連付けることです。これを機能させるのは困難です。MVVMパターンを活用するには、アプリケーションのレイヤー全体のいくつかの場所にコードを配布する必要があります。また、テンプレートやランバ式などの難解なプログラミング構造を使用する必要があります。頭を掻いて画面を見つめるもの。これにより、最近発見したように、メンテナンスとデバッグの悪夢が起こります。2度目の呼び出しで例外が発生するまで、ダイアログボックスが閉じられるとダイアログボックスを再び表示できなくなると言って、aboutボックスは正常に機能していました。ダイアログウィンドウに閉じる機能のイベントハンドラーを追加する必要がありました。それのIDialogView実装の別のものと、IDialogViewModelの最後の別のもの。MVVMがそのような贅沢なハッカーから私たちを救ってくれると思いました！

この問題に対する競合する解決策を持っている人が何人かいますが、それらはすべてハックであり、クリーンで簡単に再利用できる、エレガントなソリューションを提供していません。ほとんどのMVVMツールキットはダイアログに光沢があり、ダイアログに対処する場合、それらは単なるカスタムボックスやビューモデルを必要としないアラートボックスです。

MVVMのビューパターン、少なくともその正統な実装をあきらめることを計画しています。どう思いますか？あなたが何かあったとしても、それはあなたにとって問題の価値がありましたか？私は単に無能なプログラマーなのでしょうか、それともMVVMが期待されているものではないのですか？

Question 2

私の答えが少し長くなったら申し訳ありませんが、私を責めないでください！あなたの質問も長いです。

要約すると、MVVMは無意味ではありません。

明確な例として、モーダルダイアログボックスのサポートが追加されています。正しい方法は、ダイアログボックスを表示してビューモデルに関連付けることです。これを機能させるのは困難です。

はい、そうです。
ただし、MVVMは、UIの外観をロジックから分離する方法を提供します。どこでもそれを使用することを強制する人は誰もいません。誰もがあなたの額に銃を構えて、すべてに対して個別のViewModelを作成することはありません。

これがこの特定の例に対する私のソリューションです
。UIが特定の入力を処理する方法は、ViewModelのビジネスではありません。ビューの.xaml.csファイルにコードを追加します。これにより、ダイアログボックスがインスタンス化され、同じViewModelインスタンス（または必要に応じて何か）がDataContextとして設定されます。

MVVMパターンを活用するには、アプリケーションのレイヤー全体のいくつかの場所にコードを配布する必要があります。また、テンプレートやランバ式などの難解なプログラミング構造を使用する必要があります。

まあ、いくつかの場所でそれを使用する必要はありません。これは私がそれを解決する方法です：

XAMLをビューに追加し、.xaml.csには何も追加しません
ViewModel内にすべてのアプリロジックを記述します（UI要素で直接動作するものを除く）
UIで実行する必要があるがビジネスロジックとは何の関係もないすべてのコードは、.xaml.csファイルに入ります

MVVMの目的は、主にアプリケーションのロジックと具象UIを分離することであり、したがってUIの簡単な変更（または完全な置き換え）を可能にすることだと思います。
私は次の原則を使用します。ビューは、ViewModelから必要なものをすべて認識して想定できますが、ViewModelはビューについて何も認識できません。
WPFは、まさにそれを実現するために使用できる素晴らしいバインディングモデルを提供します。

（ところで、テンプレートとラムダ式は、正しく使用すれば難解なものにはなりません。ただし、使用したくない場合は使用しないでください。）

頭を掻いて画面を見つめるもの。

ええ、私は気持ちを知っています。MVVMを最初に見たときに感じていたとおりのこと。しかし、コツをつかめば、もう悪くはありません。

私は約ボックスがうまく機能していた...

アバウトボックスの後ろにViewModelを配置するのはなぜですか？その意味はありません。

ほとんどのMVVMツールキットはダイアログに光沢があり、ダイアログに対処する場合、それらは単なるカスタムボックスやビューモデルを必要としないアラートボックスです。

はい、UI要素が同じウィンドウまたは別のウィンドウにある、あるいは現在火星を周回しているという事実自体は、ViewModelsの懸念事項ではありません。
関心事の分離

編集：

タイトルが「自分のMVVMフレームワークを構築する」です。見る価値があります。

Question 3

これを機能させるのは困難です。MVVMパターンを活用するには、アプリケーションのレイヤー全体のいくつかの場所にコードを配布する必要があります。また、テンプレートやランバ式などの難解なプログラミング構造を使用する必要があります。

ありふれたモーダルダイアログボックスの場合あなたは間違いなくそこで何か悪いことをしています-MVVMの実装はそれほど複雑である必要はありません。

あなたがMVVMとWPFの両方に不慣れであることを考えると、どこでも次善のソリューションを使用していて、不必要に複雑になっている可能性があります。少なくとも、私が初めてWPFに行ったときにそうしました。あきらめる前に、問題が本当にMVVMであり、実装ではないことを確認してください。

MVVM、MVC、Document-Viewなどは古いパターンのファミリーです。欠点はありますが、説明したような致命的な欠陥はありません。

Question 4

私はPRISMを使用した非常に複雑なMVVM開発の真っ最中なので、すでにこの種の懸念に対処する必要がありました。

私の個人的な結論：

MVVM対MVC / PopUps＆co

MVVMは本当に素晴らしいパターンであり、ほとんどの場合、WPFの強力なデータバインディングによりMVCを完全に置き換えます
プレゼンターからサービスレイヤーを直接呼び出すことは、ほとんどの場合、正当な実装です
{Binding Path = /}構文のおかげで、非常に複雑なList / Detailシナリオでも純粋なMVVMで実装できます
それにもかかわらず、複数のビュー間の複雑な調整を実装する必要がある場合、コントローラーは必須です
イベントを使用できます。IView（またはAbstractObserver）インスタンスをコントローラーに格納することを意味する古いパターンは廃止されました
コントローラは、IOCコンテナによって各Presenterに挿入できます
PrismのIEventAggregatorサービスは、コントローラーの唯一の使用がイベントディスパッチである場合の別の可能なソリューションです（この場合、コントローラーを完全に置き換えることができます）。
ビューが動的に作成される場合、これはコントローラーにとって非常に適したジョブです（プリズムでは、コントローラーはIRegionManagerに注入（IOC）されます）。
モーダルダイアログボックスは、必須の確認などの実際にブロックする操作を除いて、最近の複合アプリケーションではほとんど使用されていません。これらの場合、モーダルアクティベーションは、コントローラー内で呼び出されるサービスとして抽象化され、特殊なクラスによって実装されます。これにより、高度なプレゼンテーションレベルのユニットテストも可能になります。たとえば、コントローラーはIConfirmationService.RequestConfirmation（ "are you sure"）を呼び出します。これにより、実行時にモーダルダイアログ表示がトリガーされ、単体テスト中に簡単にモックできます。

Question 5

私は不正行為によって対話の問題に対処します。MainWindowは、アプリケーション固有のすべてのダイアログを公開するIWindowServicesインターフェイスを実装しています。次に、他のViewModelでサービスインターフェイスをインポートし（MEFを使用しますが、インターフェイスをコンストラクターに手動で渡すだけで簡単にできます）、それを使用して必要なことを実行できます。たとえば、これは私のユーティリティアプリケーションのインターフェイスの外観です。

//Wrapper interface for dialog functionality to allow for mocking during tests
public interface IWindowServices
{
    bool ExecuteNewProject(NewProjectViewModel model);

    bool ExecuteImportSymbols(ImportSymbolsViewModel model);

    bool ExecuteOpenDialog(OpenFileDialog dialog);

    bool ExecuteSaveDialog(SaveFileDialog dialog);

    bool ExecuteWarningConfirmation(string text, string caption);

    void ExitApplication();
}

これにより、すべてのダイアログ実行が1か所に配置され、単体テスト用に簡単にスタブできます。ダイアログのクライアントが適切なViewModelを作成しなければならないというパターンに従います。ViewModelは必要に応じて構成できます。Execute呼び出しはブロックし、その後クライアントはViewModelの内容を見てダイアログの結果を確認できます。

より「純粋な」MVVM設計は、よりクリーンな断熱材とより複雑な構成が必要な大規模なアプリケーションでは重要かもしれませんが、中小規模のアプリでは、必要なフックを公開する適切なサービスを備えた実用的なアプローチで十分だと思います。

Question 6

デザインパターンは、あなたを助けるためのものであり、妨げるものではありません。優れた開発者であることのほんの一部は、「ルールを破る」タイミングを知ることです。MVVMがタスクにとって扱いにくく、将来の価値は努力に値しないと判断した場合は、パターンを使用しないでください。たとえば、他のポスターがコメントしているように、単純なaboutボックスを実装するためになぜすべてのオーバーヘッドを経験するのですか？

デザインパターンは、独断的に従うことを意図したものではありません。

Question 7

パターン自体としてMVVMは素晴らしいです。しかし、NET 4.0データバインディングサポートに付属するWPFの制御ライブラリは非常に制限されており、WinFormよりもはるかに優れていますが、それでもバインド可能なMVVMには十分ではありません。
バインド可能なMVVM：データバインディングのみを使用してViewModelがViewに接続されているUIです。
MVVMパターンはViewStateのオブジェクト表現に関するものであり、ViewとViewModelの間の同期を維持する方法を記述していません。WPFではデータバインディングですが、何でもかまいません。実際に、MVVMパターンは、events \ callbacksをサポートする任意のUIツールキットで使用できます。WinFormsの純粋なWinAPIで使用できます（私はそうでした。events\ callbacksでの作業はそれほど多くありません）。Textでも使用できます。コンソール、MVVMパターンを使用してDoSのノートンコマンダーを書き換える。

つまり、MVVMは無意味ではなく、すばらしいものです。NET 4.0 WPFの制御ライブラリはゴミです。

これは、WPFを使用して純粋なMVVMの方法でデータバインドできない単純な概念実証モデルです。

public class PersonsViewModel
{
    public IList<Person> PersonList;
    public IList<ColumnDescription> TableColumns;
    public IList<Person> SelectedPersons;
    public Person ActivePerson;
    public ColumnDescription SortedColumn;
}

WPFのDataGrid列ヘッダーをデータバインドしたり、選択した行をデータバインドしたりすることはできません。コードを単純な方法で行うか、これらの5行の最も単純なViewModelに対して200行のXAMLハックコードを記述します。複雑なViewModelで事態がさらに悪化することを想像するしかありません。
したがって、Hello Worldアプリケーションを作成していない限り、WPFでバインド可能なMVVMを使用しても意味がありません。ViewModelをバインドするためのハックにほとんどの時間を費やします。データバインディングは適切ですが、イベントの70％の時間にフォールバックする準備ができています。

Question 8

いいえ、それは無意味ではありませんが、パターン自体は途方もなく単純ですが、あなたの頭を包むことは困難です。そこにはたくさんの誤った情報があり、適切な方法をめぐって戦うさまざまなグループがあります。WPFとSilverlightでは、MVVMを使用する必要があります。そうしないと、コーディングをやり直して、新しいモデルの問題を解決しようとするだけで、トラブルにつながる「古い」勝利フォームの方法論になります。すべてが非同期である必要があるため、これはSilverlightの場合に当てはまります（これを回避することは可能ですが、別のプラットフォームを選択する必要があります）。

この記事を読んで、ViewModelパターンを使用してWPF TreeViewを簡略化する方法を注意深く読んで、MVVMを適切に実装し、勝利フォームの考え方をMVVMの新しい考え方に変える方法を確認してください。つまり、何かを実行したい場合は、まずロジックをビューではなくビューモデルに適用します。アイテムを選択しますか？アイコンを変更しますか？UI要素を繰り返し処理するのではなく、モデルのプロパティを更新して、データバインディングに細心の注意を払ってください。

Question 9

（モーダル）ダイアログに関して、多くのMVVM実装で同じ問題が発生しました。MVVMパターンの参加者を見ると、一貫性のあるアプリケーションを構築するために何かが足りないと感じています。

ビューには、特定のGUIコントロールが含まれ、ユーザーインターフェイスの外観を定義します。
ViewModelは、プレゼンテーションの状態と動作を表します。
モデルは、ドメインレイヤーのビジネスオブジェクト、または必要なデータを提供するサービスです。

しかし、不足しているのは：

誰がViewModelを作成しますか？
アプリケーションワークフローの責任者は誰ですか？
互いに通信する必要があるときに、誰がViewModelを仲介するのですか？

私のアプローチは、不足点の原因となる（ユースケース）コントローラーを導入することです。これがどのように機能するかは、WPFアプリケーションフレームワーク（WAF）サンプルアプリケーションで確認できます。