MVVMの明確化

最初のWPFアプリケーションを作成しようとしており、MVVMパターンに精通しています。私たちは多くのWinformアプリケーションを構築しており、非常に成功したアーキテクチャを持っています。そのアーキテクチャを翻訳したり、アーキテクチャの特定の部分がMVVMモデルに適合する場所を決定したりするのに少し苦労しています。

歴史的には、BusinessLogic dllと通信するGui（メインexe）があります。BusinessLogicはWebサービスを介してDAL dllと通信し、DALはDBと対話します。DAL、BusinessLogic、およびGUIはすべて同じBusinessObjects dllを参照します。

MVVMへの移行の一部はかなり単純です。Guiにはビューが含まれ、BusinessOjbectsにはモデルが含まれ、DALはDBと対話します（ただし、それらを実装するテクノロジーは変更される可能性があります）。

わからないのは、BusinessLogicコンポーネントです。歴史的には、これはビューのコントロールを呼び出すためにGUIに呼び出す関数を提供していました（つまり、Customerオブジェクトのリストまたは典型的なCRUD関数を返すGetCustomerList）。

主な問題は、MVVMパターンがViewModelを格納するために追加のコンポーネントを必要とするのか、単に考え方を変えてBusinessLogicコンポーネントとして使用したものをViewModelに移行するだけなのか、ということです。

BusinessLogicコンポーネントはViewModelを表しますか？

一般的に、ビジネスモデルをビューモデルレイヤーに配置しません。しかし、「ビジネスロジック」という用語は誤解を招くものです。

エリックエヴァンスは、ビジネスロジックが2つのカテゴリに分かれているモデルを使用しています

• ドメインロジック-解決しようとしている実際の問題ドメインに関連するロジック
• アプリケーションロジック-アプリケーションを構築しているという事実に関連するロジック

彼は、会計アプリケーションの例を言及しています。アカウント、投稿、税アカウントなどに関するルールは、ドメインルール、アカウンティングのドメインに関連するルールです。CSVのインポート/エクスポートに関するロジックは、アカウンティングのドメインとは関係ありません。これらのルールは、ソフトウェアアプリケーションを構築しているために存在します。これらはアプリケーションロジックの例です。

ドメインルールは、ビューモデルレイヤーに絶対に入れないでください。MVVMパターンに従っている場合、ドメインルールは問題なくモデルレイヤーに移動します。

アプリケーションルールは、CSVのインポート/エクスポートのように、可能性ビューモデル層に行きます。しかし、個人的には、それを個別のアプリケーションロジックレイヤーに分離することを好みます。

ビューモデルは非常にシンプルである必要があります。対応するモデルのビューに必要なデータを検索し、ビューが変更されたときにモデルを更新し、モデル内のイベントをリッスンし、それらのイベントをビューに伝播し、モデルが舞台裏で更新されたときにビューを更新できるようにします（該当する場合）。

個人的には、ビューモデルレイヤーに、プレゼンテーションロジックという1種類のロジックのみが含まれるようにします。

はい。

ビジネスロジック層はVM層で表されます。したがって、メンタルモデルを移行するだけです。

メンタルモデルの移行を支援するための微妙な違いは、GUI（ビュー）オブジェクトをVMレイヤー内のオブジェクトにバインドすることです。このバインディングは|に変換されます は、ビューが他の何かを取得するために「呼び出しを行う」レイヤーではなくなったことを意味します。データ取得の呼び出しは、代わりにVMから行われます。

わかりやすく説明します。はい、ビュー内のオブジェクトは、呼び出しを行う一連の操作をトリガーするために変更する必要があります。しかし、ビューはそれ自体を呼び出しません。この場合、ボタンのクリックは、ビュー内の何かが変化するのと同等であると考えますが、それでも呼び出しは行いません。

最初のケースでは、そのViewオブジェクトはVMオブジェクトにバインドされます。VMは、バインドされたオブジェクトのプロパティ変更イベントをリッスンする必要があります。その後、オブジェクト変更イベントをVM関数に接続して、モデルを呼び出します。

2番目のケース（ボタンクリックイベント）では、変更（クリック）イベントをVMによって公開される関数呼び出しに関連付けることができます。

いずれにせよ、それは常にVMにシーケンスするイベントであり、次にモデルを呼び出し、次にモデルがDAL / DBを呼び出します。

いくつかのWinFormコードを使用して、WinForm GUIのコードビハインドから直接DBレイヤーへの呼び出しを行うため、これを取り上げます。このアプローチは、MVVMが提供している分離を破ります。

基本的に、BusinessLogic dllをViewModelレイヤーに置き換えることは正しいですが、直面する最大の違いは、View / UIレイヤーがViewModel / BusinessLogicレイヤーと対話する方法だと思います。

WinFormsでは、GUIがアプリケーションであり、アプリケーションフローを担当します。WPF / MVVMでは、ViewModelはアプリケーションであり、GUIはViewModelとやり取りするためのユーザーフレンドリーなインターフェイスになります。

たとえば、WinFormsでは、DataGridとButtonがあり、そのButtonをクリックするBusinessLogicLayer.GetProducts()と、結果のProductオブジェクトを呼び出してDataGridにロードします。

WPFでは、ObservableCollection<Products>とを含むViewModelがICommand GetProductsあり、コマンドを実行するとDALが呼び出され、製品のコレクションがロードされます。ただし、これにユーザーフレンドリーなインターフェイスを提供するには、ProductsコレクションにDataGridを使用し、GetProductsコマンドにButtonを使用してViewModelをレンダリングするViewを作成します。

私は実際、ブログでWinformsからWPFに移行するときの考え方の変化について、かなり最近のブログに投稿しました。違いを要約する最良の方法は、これらの写真を使用することです。