3

私たちのアプリケーションはコントローラーを小さく保つために最善を尽くし、ビューは UI に関係しており、モデル データを取得するビューごとに ViewModel があります。AutoMapper を使用して、モデルを ViewModel にマップすることができました。

場合によっては、ViewModel を構築するために必要なかなりの量のコードを用意していますが、これは技術的には AutoMapper の Map 機能で実行できますが、巨大で見苦しくなります。したがって、一部の ViewModel に組み込まれたこのビットのロジックがありますが、それらは 200 行以上の長さになり、正しく感じられません。たとえば、1 つの ViewModel には、単一のモデルから派生したのではなく、約 4 ~ 5 個のモデルから派生した約 6 個のプロパティがあり、実行時に計算されるという点で動的であるため、名前パラメータをViewModel にモデル化します。

他の誰かがこの問題に遭遇したり、単一のモデルから簡単に構築できない ViewModel のために何らかの ViewModel ファクトリを作成する必要があることを発見しましたか?

編集

例: 「Beginning French 101」などのコースのページがあるとします。コース モデルには、教師、科目、前提条件、クラス番号、セクションなどがあります。学生がコース ページにアクセスしたときに、このクラス (または他のクラス) についてどのように、またはどのような追加情報が表示されるかを変更したい場合があります。学生の登録状況、登録、過去の履歴、学生が登録している他のクラスなど。ここには Course と Student の 2 つのモデルがありますが、特定のビジネス ルールに基づいて ViewModel 内に含める追加情報を取得したい場合があります。 .

4

1 に答える 1

2

ビジネス ロジックの場合は、マッピング レイヤーに配置しないでください。Dtosビジネス層で可能な限りオブジェクトを定義して準備します。ビジネス モデルとビュー モデルの間にこのような大きな違いがある場合は、多額のビジネス ドメイン モデルをデータ転送オブジェクトに変換する別のレイヤーがおそらく必要であることを意味します。一般に、複雑なビジネス ロジックをマッピング レイヤーに配置することは避けるべきです。

残念ながら、あなたの側からの特定のコード サンプルがなければ、これ以上拡張することは困難です。

于 2012-09-24T14:14:03.963 に答える