3

私の質問は、モデルであるMVVMの最初の「M」に関するものです。モデルの実装方法には多くのバリエーションがあります。ビジネス ロジックも永続化ロジックも持たない POCO だけのものもあれば、一方または両方を含むものもあります。

現在、私たちのアプリケーションでは、モデル、ビュー、およびビューモデルが適切に分離されています。これは、現在のソリューション構造です (WPF プリズム アプリケーション)。

  • インフラストラクチャー
  • モジュール A
    • ビューモデル
    • ビュー
  • モジュール B
    • ビューモデル
    • ビュー
  • モデル (モジュール間で共有されているため、独自のクラス ライブラリにあります)
  • サービス
  • DataAccess (おそらく dapper-dot-net を利用)
  • シェル (メインの WPF プロジェクト)

次に、データベースに対して CRUD を実行し、モデルを最新の状態に保つ方法を理解する必要があります。モデルを必要最低限​​の状態に保ち、ビジネス ロジックを含み、データ アクセス クラスに対して作業単位パターンを実行する「サービス」クラス ライブラリを用意するというアイデアが気に入っています。モデルを馬鹿にして、ビジネス ロジックやデータ アクセスを無視することに関する既知の問題はありますか? これはMVVMで行うのはかなり珍しいことですか?

モデルにロジックを配置しないことで、自分自身を制限したり、必要以上に複雑にしたりしているのではないでしょうか。たとえば、引数を指定して ctor 内からモデルをロードするなどです。注意として、これは大きなアプリケーションになります。

私たちのアプリケーションは、モデルを複数のデータベースに永続化する必要があります。サービスの依存性注入コンテナーとして Unity を使用しています。どのデータ接続を使用するかをサービスに伝えるにはどうすればよいですか? Ctor、関数ごとなど?

似たような構造を構築した人を探していて、彼らの経験や推奨事項は何ですか。

4

1 に答える 1

5

私の見解では、MVVM モデルはデータを「表す」だけなので、ロジック、CRUD、その他の方法で埋め込むべきではありません。既にデータ アクセス レイヤーがあるため、そこに CRUD コードを記述し、DI を使用してモデルからこの CRUD コードにアクセスするのはまったく普通のことです。

MVVM の「美しさ」は、解釈が自由であることです。他の誰かが、モデルはデータであり、CRUD ロジックを含むことができると主張するでしょう...

私はすべての CRUD 操作を DAL に持っていますが、そのアプローチの欠点はまだ見ていません...

于 2012-05-30T18:21:11.570 に答える