0

次のようなクラスを返すドメイン データ モデルがあります。

public class ZombieDeath
{
    public virtual int ZombieId {get;set;}
    public virtual FatalHit {get;set;}
}

public class FatalHit
{
    public virtual int HitId {get;set;}
    public virtual string Zone {get;set;}
    public virtual string Weapon {get;set;}    
}

このデータをグリッドに戻すときは、データを常にフラットな形式でビューに返すのが最善であると読みました。したがって、グリッド行を表す次のクラスがあります。

public class ZombieDeathRow
{
    public virtual int ZombieId {get;set;}
    public virtual int HitId {get;set;}
    public virtual string Zone {get;set;}
    public virtual string Weapon {get;set;}
}

したがって、これがレンダリングされるときはModel.Weapon、 の代わりに , を呼び出すだけですModel.FatalHit.Weapon。これにより、ビューのコードが読みやすくなりますが、マッピングが必要なため、明らかに追加の作業レイヤーになります。

これは本当に良い働き方なのか、それとも単に時間の無駄なのか?

4

3 に答える 3

3

プレゼンテーション層とドメインで異なるデザインにするメリットはあると思います。つまり、概念的には、実際には 2 つの異なるモデルを見ています。1 つはドメイン層用で、もう 1 つはプレゼンテーション層用です。各モデルは、目的に合わせて最適化されています。

ドメイン層は、使用しているユーザー インターフェイスに関係なく、アプリケーション ドメインの表現を提供することを目的としています。

プレゼンテーション層のモデルは、使用しているユーザー インターフェイス テクノロジや使用しているクライアントによって異なります。たとえば、プレゼンテーション層のモデルは、MVC と WebForms では異なるように見える場合があります (両方を並行して使用している人もいます)。モバイル デバイスのプレゼンテーション レイヤーのモデルは、デスクトップで実行されているブラウザーのモデルとは異なる場合があります。Web サービスは、さらに別のモデルを使用してデータを効率的に送信する場合があります。Web アプリケーションで AJAX を使用する場合は、JSON などを使用して情報を効率的に送信するために、さらに別のモデルを使用することをお勧めします。

ですから、そうです、一般的には、理解と保守が容易な方法でシステムを実装するのに役立つ限り、さまざまなモデルを使用してもまったく問題ないと思います。ビューのコードは「読みやすい」と述べています。私の意見では、それは理由として十分です！

于 2010-08-02T11:42:43.303 に答える
1

時間の無駄 IMO。最も単純なソリューション以外では、マッピング コードの作成に多くの時間を費やすことになります。

ViewModel をフラット化するのが最善であるとどこで読みましたか? ViewModel のプロパティとして公開された複雑なビジネス オブジェクトは、完全にカプセル化されたコードを促進しない可能性がありますが、MVC プロジェクトでの私の経験では、優れたドメイン モデルは、純粋主義者を除いてこれが問題にならないことを意味します。

于 2010-08-02T11:40:21.560 に答える
0

リレーショナル データ構造を見ていますが、これは第 3 正規形を維持するのが最適です。FatalHitこのコードから、なぜ分離する必要があるのか​​ わかりませんZombieDeath。1つのクラスで合体させると第3正規形を失うのですか？他のクラスにはFatalHitメンバーがいますか?

このデータを表すために 2 つの別個のクラスが必要であり、結合された 3 番目のクラスがビューで簡単に作業するためだけに使用される場合、3 番目のクラスには意味がありません。

于 2010-08-02T11:40:48.170 に答える