2

始める前に、ViewModel とは何か、その目的は何かを知っていると言いたいのですが、このシナリオでは冗長になります..読み進めてください :)

私は ASP.NET MVC4 アプリケーションに取り組んでおり、PagedList、Domain Entities、および ViewModel に関して頭痛の種に遭遇しました。

基本的に、PagedList.MVC プラグインは AutoMapper とうまく連携しません。必要に応じて機能させるために余分な作業を行う必要があります。

しかし、問題のドメイン エンティティのすべてのプロパティが必要な場合、ViewModel クラスは必要でしょうか?

ビューでドメイン エンティティのすべてのプロパティが必要な場合、ViewModel にはどのような利点がありますか?

4

2 に答える 2

2

それは意見の問題かもしれませんが、私はビュー モデル (および DTO) を使用するのが好きです。これにより、次の利点が得られます。

  • ビューに必要なすべてのデータがロードされ、プロキシなどではないと確信しています.
  • 正しく作成された場合、DTO はキャッシュに格納するためのはるかに小さなグラフを提供します (セットアップには適用されない場合があります)。
  • これにより、ビュー モデルを Domain オブジェクトと大きく変えることができます。多くの場合、それらは複合体であり、非常に平坦化されており、アプリケーションの他の部分に影響を与えることなく自由に変更できます。

上記に対抗するために、多くの人がそうするでしょうが、ドメイン オブジェクトを直接操作できます。ビュー モデルが単にドメインの 1 対 1 の類似物であり、上記のメリットが見られない場合は、これもお勧めします。

いつものように、それはあなたの設定に依存します

  • あなたのチーム
  • あなたを生産的にするものは何ですか
  • ツールが使用され、ORM が使用された場合
  • プロジェクトの規模と期間
  • 経験
  • などなど
于 2014-02-20T14:24:36.117 に答える
1

小規模なプロジェクトの場合は、それを追加したいと思います。独自の ViewModel を用意して、それを操作しても問題ありません。エンティティが必要な場合は、後でエンティティを分離できます。

長所と短所を考慮せずに新しいレイヤーを追加する多くの開発者は、遅れに気づき始め、疑問が生じます。MVC 自体はすでに関心の分離です。

別の DomainEntity を持つことで、UI が 1 対 1 でエンティティにマップされなくなるという別の問題が解決されます。次の点を考慮してください。

Version 1
Domain              | Presentation  
--------------------------------
User.FirstName      | User.Name
User.LastName       |
User.PositionTitle  | User.PositionTitle

この例は、ドメインとプレゼンテーションが 1 対 1 でマップされていないことを示しています。将来、次のようなドメイン変更が発生する可能性があります。

Version 2
Domain              | Presentation  
--------------------------------
User.FirstName      | User.Name
User.LastName       |
Position.Title      | User.PositionTitle

上記の例 (バージョン 2) に基づいて、プレゼンテーションが変更されていないことに注意してください。分離されたドメイン モデルを持つことで、インターフェイスの安定性が向上します。リファクタリング シナリオの変更コストを削減することもできます。

ViewModel の利点

ViewModel の優れた点は、ドメインをプレゼンテーションから切り離すことです。この利点は、さまざまな開発者がシステムのさまざまな部分を処理する大規模なプロジェクト (たとえば、別の GUI チーム) で採用された場合により明白になります。

1 つの小さな変更で、多くのクラスを変更する必要があります。

これは、エンティティを切り離すことの欠点の 1 つであり、コードの重複が生じます。追加のコーディングには莫大なコストがかかり、それに見合うだけのメリットが明らかでなければなりません。

于 2014-02-21T05:44:46.183 に答える