2

ビュー モデルを使用して、ASP.NET MVC プロジェクトのアクション メソッドをクリーンアップしようとしています。現在、私のビュー モデルには、他のエンティティとの関係を持つ可能性のあるエンティティが含まれています。たとえば、ContactViewModel クラスには Contact があり、これには Address があり、どちらも別個のエンティティです。Contact オブジェクトのリストを照会するには、次のようにします。

IList<Contact> contacts;

using (IContactRepository repository = new ContactRepository())
{
    contacts = repository.Fetch().ToList();
}

EditContactViewModel vm = new EditContactViewModel(contacts);

return View(vm);

この方法は、いくつかの問題を引き起こします。たとえば、リポジトリは using ステートメント内でクエリされます。ビューがレンダリングされるまでに、コンテキストは範囲外になり、ビューは Contact に関連付けられた Address を照会できなくなります。熱心な読み込みを有効にすることもできましたが、そうしないほうがよいでしょう。さらに、エンティティ モデルがビューに染み込んでいるのが気に入りません (ビューが Contact と Address の関係を認識しているのは悪い考えだと思いますが、私に異議を唱えることは自由です)。

Contact エンティティと Address エンティティの両方のプロパティを含むファット クラスを作成することを検討しました。次に、Contact エンティティと Address エンティティを新しいフラット化されたオブジェクトに射影できます。このアプローチに関する私の懸念の 1 つは、アクション メソッドが少し忙しくなる可能性があり、AutoMapper が 2 つ以上のオブジェクトを 1 つの型にマップできないと思うことです。

私の懸念を克服するためにどのようなテクニックが好まれていますか?

4

2 に答える 2

1

これらの懸念事項を整理すると...

まず、using ステートメントとリポジトリが心配な場合 (LINQ-to-SQL か LINQ-to-Entities かはわかりませんが、問題ではありません)、私がお勧めするのは、実装することです。コントローラーでIDisposableを作成し、モデルまたはコントローラーのフィールド、またはビューでアクセスできる場所にリポジトリを保存します(必要な場合、オブジェクトが「生きている」場合は、コントローラーの存続期間中、それを維持する必要があります)。

次に、リクエストが完了すると、コントローラーの Dispose メソッドが呼び出され、そこでリポジトリを破棄できます。

個人的には、次のような基本コントローラー クラスのメソッドがあります。

protected T AddDisposable<T>(T disposable) where T : class, IDisposable
{
    // Error checking.
    if (disposable == null) throw new ArgumentNullException("disposable");

    // Add to list
    ...
}

基本的には、IDisposable の実装を格納できます。次に、コントローラーの IDisposable の実装で、リストを反復処理し、すべてを破棄します。

エンティティ モデルでのアドレスの公開に関しては、個人的には、これは裁ち落としの問題とは考えていません。アドレスは連絡先 (IMO) の構成の一部であるため、そこにないのは正しくありません

ただし、一度に 1 つのコントローラーの 1 つのタイプに集中したいなどの理由で、そこに配置したくない場合でも、私は同意しません。

そのためには、ビュー モデルで公開するタイプとエンティティ モデルの間で基本的にマップするデータ転送オブジェクトを作成する必要があります。

于 2010-02-15T23:10:07.707 に答える