1

この q/a Real example of TryUpdateModel, ASP .NET MVC 3 を読み、 @ben-foster の応答に本当に興味を持っていました。

私はその答えについてコメントを始めましたが、かなり長くなったので、新しい質問を始めました。

すべてのアプローチに ViewModel を使用すると (私はこれがとても気に入っています)、どうすればよいかについてアドバイスが必要な「奇妙なシナリオ」に陥ります。

この構造を想像してください:

public class ProductListEditableViewModel {
    List<ProductEditViewModel> products {get;set;}
}
public class ProductEditViewModel {
    List<PriceViewModel> prices {get;set;}
}

public class PriceViewModel {
    CurrencyViewModel currency {get;set;}
}

等々 ... ？内部クラスごとに 1 つのビュー モデルを本当に作成しますか? では、それをすべてモデル オブジェクトにマップするにはどうすればよいでしょうか。

また、それは編集をカバーしていますが、私は追加、電子メールによる送信、そして潜在的により多くのビューを持っているので、より多くのビューモデルを持っています!! 私は何かのように終了する必要があります:

AddCurrencyViewModel QuickAddCurrencyViewModel EditCurrencyViewModel ListCurrencyViewModel DeleteCurrencyViewModel ShareCurrencyViewModel

すべてが「ほぼ同じ」プロパティを持っていますか?

それらすべてを 1 つのファイルにまとめる必要がありますか?

また、このすべてのビューモデルが必要ですか、それとも継承アプローチの方が良いでしょうか?

可能であれば、複雑なシナリオについて詳しく説明していただければ幸いです

また、モデル オブジェクトの一部を Web サービス / API に公開するために DTO アプローチを使用しているため、この DTO が正確に私の ViewModel ではない場合、何らかの形式のマッピングが既に配置されています。そのうちの 1 つを削除する必要がありますか? このシナリオでの提案は何ですか?

私はエンティティフレームワークを使用していますが、問題はORMにとらわれない（またはすべきである）と思います。UoW パターンを使用しない (これは役に立ちますか?) オブジェクトの深さが増すにつれて複雑になるように見えます。

どうもありがとう！

4

2 に答える 2

2

私たちは通常、ビューごとにビュー モデルを持っているので、そうです。多くのビューがある場合は、多くのビュー モデルがあります。

典型的な CRUD アプリケーションでは、Add や Update などの非常によく似たビューを使用することがよくあります。これらの場合、はい、重複したコードを書くのではなく、継承を使用します - 通常、サブクラスを追加して更新します。

public class AddFoo : UpdateFoo {
    public AddFoo() {
        // set up defaults for new Foo
    }
}

public class UpdateFoo {
    public string Name { get; set; }
    // etc.
}

過去にビュー間でビューモデルを「共有」しようとしましたが、通常は苦痛の世界に終わりました。

あなたの「奇妙なシナリオ」に関して-これは確かに奇妙に見えますが、おそらくあなたのアプリケーションを理解していないためです。

ビュー モデルの目標は、必要な情報をビューに提供し、理想的には複雑なオブジェクトをフラットにして操作しやすくすることです。理にかなっていない限り、ビューモデルを例のように分割しないでください。

顧客が連絡先の詳細を変更できるビューを作成したいとしましょう。次のドメイン オブジェクトを取得します。

public class Customer {
    public string FirstName { get; set; }
    public string LastName { get;set; }
    public Address Address { get; set; }
}

私はおそらくこれを次のようなビューモデルにフラット化します:

public class UpdateAddressModel {
    public string FirstName { get; set; }
    public string LastName { get; set; }
    public string AddressLine1 { get; set; }
    public string AddressLine2 { get; set; }
    public string AddressCity { get; set; }
    // etc.
}

もちろん、これを行う意味がない場合もあります。たとえば、在庫切れの製品のリストと最近の注文のリストがあるオンライン ストアのダッシュボード ビューなどです。これら 2 つのことは無関係ですが、あなたの見解では以下が必要です:

public class DashboardModel {
    public List<Product> ProductsGoingOutOfStock { get; set; }
    public List<Order> NewOrders { get; set; }
}

では、それをすべてモデル オブジェクトにマップするにはどうすればよいでしょうか。

モデル オブジェクトとは、データ/ドメイン モデルを意味すると仮定しています。ここで重要なことは、ビューをレンダリングするために使用するビュー モデルが、サーバーに POST する「モデル」と同じである可能性は低いということです。あなたの目を出血させるすべてのデータキャプチャ画面。

サーバーに送信するものをコマンドとして、ビューをレンダリングするために使用するものをビュー モデルとして考えると役立つと思います。

それでは、あなたの質問に対する答えです。複雑なビュー モデルをデータ モデルにどのようにマッピングしますか? - 簡単に言えば、そうではありません。アドレスの更新など、特定のタスクを実行するコマンドをサーバーに送信する必要があります。

ビュー モデルをどのように構築するかについて厳格な規則はありませんが、一般的には理にかなった方法で行います。複雑すぎると感じ始めた場合は、おそらく 1 つのビューで多くのことを実行しようとしています。

これが役立つことを願っています。私のブログには、この問題に関連する多くの投稿があります。

于 2013-02-26T10:30:39.757 に答える