4

私の仕事では、MVVM パターンを使用して実装された WPF プロジェクトに割り当てられています。コードビハインドがゼロのビューがあり、クールです。Entity Frameworkによって生成されたデータモデルをモデルとして（他のいくつかのクラスとともに）使用しますが、これは適切なアプローチであるとは思えません。しかし、私を最も悩ませているのは、すべてのビジネス ロジックとアプリケーション/操作コードが存在する最も厚いレイヤーとして ViewModel があることです。

現在、私は WPF/MVVM の初心者ですが、MVVM パターンについての私の理解では、ViewModel はモデルを消費できるようにビューに手段を提供することだけが想定されているため、すべての中で最も薄いレイヤーになります。ビジネス ロジックとアプリケーション/オペレーション コードは別の場所に置く必要があります。

誰かが私を助けてくれれば、本当に感謝しています。ViewModel の目的について、私は正しいですか、間違っていますか? ビジネス ロジックとアプリケーション/操作コードを別の場所に配置する必要がありますか?それとも、ViewModel をビジネス ロジック レイヤーと見なすだけですか?

4

1 に答える 1

8

はい、非常に単純な数学計算でない限り、ビュー モデルにビジネス ロジックを含めないことに同意します。私が働いている会社は、すべてのビジネス ロジックをモデルに保持することを好みます。個人的には、プロジェクトには、このすべてのロジックを処理するサービス レイヤーが必要だと思います。しかし、はい、ビューモデルはビューに集中し、入力を取得して送信し、できれば INotifyPropertyChanged インターフェイスによって値/プロパティを更新する必要があります。私は、ビュー モデルを、通行を管理する学校の「交差点警備員」と考えるのが好きです。:P - これが役立つことを願っています

于 2012-08-21T00:35:43.940 に答える