0

LINQ-SQL を使用して SQL Server データベースに接続する MVC アプリケーションに取り組んでいます。

現在、データをフェッチするときに、LINQ オブジェクトのプロパティをドメイン モデルに渡し、そのドメイン モデルのプロパティをビュー モデルに作成しています。

たとえば、View Model には次のプロパティがあるとします。

public Models.UserModel user { get; set; }
public List<Models.CountryModel> countries { get; set; }

私のドメイン モデルには、私の LINQ オブジェクトとまったく同じプロパティがあり、これらのプロパティを次のようにコピーします。

Models.UserModel user = new Models.UserModel();
user.Username = User.Username;
user.FirstName = User.FirstName;
user.LastName = User.LastName;

user私のModels.UserModelオブジェクトはどこにありUser、ユーザーデータベーステーブルからマップされた私のLINQオブジェクトはどこですか。

私のドメイン モデルは私の LINQ オブジェクトとまったく同じなので、このデータをドメイン モデルに転送する利点はありますか、またはビュー モデルで次のような LINQ オブジェクトを使用しても問題ありませんか?

public User user { get; set; }
public List<Country> countries { get; set; }

ドメイン モデルを使用する利点は何ですか? これは純粋にデータベース LINQ オブジェクトと疎結合するためですか?

ドメイン モデルを使用する利点がある場合、MVC アプリケーション内でこれらをどのように構造化するのが最善でしょうか?

"Models" フォルダー レベル (たとえば、サブフォルダー "DomainModels" と "ViewModels") で完全に分割するか、または一致させる必要があります ("UserEditViewModel.cs" と "UserDomainModel.cs" など)。

4

1 に答える 1

3

私のドメイン モデルは私の LINQ オブジェクトとまったく同じなので、このデータをドメイン モデルに転送する利点はありますか、またはビュー モデルで次のような LINQ オブジェクトを使用しても問題ありませんか?

ビューモデルがまったく同じである場合は、ビューモデルでドメインモデルを参照できます。現実の世界では決して同じではないことを除いて、このロジックを複製する利点はありません。検証や表示ラベルなど、常にいくつかのビュー固有のものがあります。純粋なビュー モデルを使用する利点は、アプリケーションがデータベース構造に縛られなくなることです。UI 部分を変更することなく、データ アクセス テクノロジを簡単に切り替えることができます。私は、この明確な分離を持つ方が保守しやすいと感じており、アプリケーションでは常に分離する傾向があります。

于 2013-02-01T11:34:55.177 に答える