「ASP.NET MVC 4」という本を読んでいるときに、MVVM について疑問に思っています。私はグーグルで検索を開始しましたが、MVVM を使用した Web アプリケーションの開発に関する書籍が見つからないため、ここで少し情報が不足しているに違いありません。
私が理解していることから、MVVM は、knockout.js およびその他のフレームワークを介して、クライアント側の Web アプリケーションで使用されます。ただし、Windows Phone アプリケーションを開発する場合は、MVC を使用せずに MVVM を直接使用できます。つまり、MVVM / データ バインディングの概念は、クライアント サーバー Web アプリケーションには当てはまらないということですか?
MVVM は実際には一種のサブパターンです。実際には、「MVVM」Web アプリ フレームワークはありません。それらはすべて MVC であり、必要に応じてビュー モデルを組み込むだけです。
特に ASP.NET MVC では、クラスを作成するだけでよく、通常は [Model Name]ViewModelまたはの形式の名前が付けられ[Model Name]VMます。そのクラスには、使用する必要があるモデルのプロパティと、実際のデータベースに支えられたモデルに配置するのに意味のない余分なもの ( SelectLists など)のみが含まれます。
アクションでは、モデルの代わりにこのビュー モデルのインスタンスをビューに渡すだけです。
return View(viewModelInstance);
そしてもちろん、あなたのビューがそれを受け入れることを確認してください:
@model Namespace.To.MyViewModel
わずかに複雑な部分は、ビュー モデルをモデルに接続することです (つまり、ビュー モデル/モデルとの間でデータを取得します)。これは、プロパティを明示的にマッピングして手動で行うことも、AutoMapperなどを使用することもできます。
MVC は一方向のデータ バインディング システムです。
Model in Controllerに入力し、それを View に渡します。
MVVM は、双方向のデータバインディングです。
モデルを入力し、ビューで使用します。ビューの状態が変化すると、モデルが自動的に更新されます (逆も同様)。
つまり、MVVM / データ バインディングの概念は、クライアント サーバー Web アプリケーションには当てはまらないということですか?
いいえ、MVVM パターンをクライアント サーバー Web アプリケーションに適用できます。
実際、Asp.Net MVC は実際にこのパターンを使用します。コントローラーがビューを作成するときに、「ビューモデル」を渡すことができます。このビューモデルは、多くの場合、特定のビューが必要とするすべてのデータをモデル (データベース) から取得した POCO データ オブジェクトです。ビューは、このデータを使用して html ページをレンダリングします。
ウィキペディアの MVVM は、Microsoft によって WPF とともに導入されたと述べています。具体的には、ビューはビュー モデルのプロパティにバインドされます。ビューモデルは、これをデータベースにマップします。この定義により、Asp.Net はそれと完全には一致しません。knockout.js や vue.js などのクライアント側フレームワークは、ビューモデル プロパティを使用したこの種の双方向バインディングをサポートしています。
これらのパターンはすべて幻想的な MV* パターンに基づいています。もともとは MVC デザイン パターンと呼ばれていました。では、これは Asp.Net MVC とまったく同じパターンですか? 実際には、そうではありません。コントローラーは、そもそもまったく異なるものを意味します (ウィキペディアの MVC を参照)。元の MVC コントローラーは、ビュー経由ではなく、すべてのユーザー入力を直接処理します。次に、元の MVC パターンはデスクトップ アプリ GUI 用に設計され、Asp.Net MVC はクライアント サーバー Web アプリで使用するためにパターンを適合させました。ASP.Net コントローラーは、クライアント側の html ページがヒットできる http エンドポイントのコレクションです (例: フォーム ポスト、ページ ナビゲーション、ajax)。
そのため、M-something-V パターンが多く、一般的なパターンは MVC デザイン パターンと呼ばれることがよくあります。
もう 1 つ重要な点があります。クライアント側とサーバー側です。豊富なクライアント側 JavaScript フレームワークを導入しましたが、素晴らしい MV* パターンはここでも優れています。したがって、クライアント側の View-Model-ServerHTTPEndPoints とサーバー側の ServerHTTPEndPoints-ServerModel のようなものを持つことができます。サーバー エンドポイントは、使用している Web フレームワークまたはプログラミング言語に関係なく、Asp.Net コントローラーまたは同等のものを指します。サーバー側の観点からは、クライアント側の HTML 全体がビューです。クライアント側のモデルは、サーバーの ajax API (http エンドポイント) と通信して、データを同期したり、高度なアクションをトリガーしたりします。通常、ServerModel はデータベースです。ノックアウト/ビューでは、クライアント側の「モデル」ではなく、ViewModel になります。redux/flux で react/vue を使用する場合、クライアント側は View-ViewModel-Model-ServerHTTPEndPoints になり、モデルは redux/flux ストアになります。また、多くの場合、サーバー側でサービスが導入されます: ServerHTTPEndPoints-Service-Model. このようにして、単体テストは、Web サーバー全体を起動して HTTP 接続を確立するのではなく、サービスを直接ヒットできます。
私はデスクトップ アプリケーションで MVVM を使用しており、ビジネス オブジェクトをモデルとして保存するモデルという名前のビューモデルにプロパティがあります。私のビューには、ビューが読み込まれる前にビューモデルが格納される DataContext という名前のプロパティがあります。ビューは、パス DataContext.Model.BusObjPropertyName を使用して、そのコントロールをビジネス オブジェクトにバインドします。ビューとビューモデルの間の関係を最初から登録する UserInteractionService があります。ビューモデルが別のビューモデルを表示する必要がある場合、UserInteractionService でメソッド ShowView を呼び出し、ビューモデルをパラメーターとして渡します。次に、サービスは受け取ったビューモデルに対応するビューをインスタンス化し、ビューモデルでその DataContext プロパティを設定して表示します。
Asp で上記のようなパスへのバインディングを行うことができれば、このモデルはすべてデスクトップでも Web アプリケーションでも再利用できます。