2

MVCアーキテクチャ内のビューのロジックに関連するQ＆Aをかなり読んだことがありますが、ほとんどの場合、ビジネスロジックをビューに含めるべきではないことに同意します。ただし、これを言っても、MicrosoftのMVCフレームワークをエンティティフレームワークと組み合わせて使用​​する場合のアプローチには常に疑問があります。これは、単一のエンティティが外部キー関係に簡単にアクセスできるため、最終的には、LinqtoEntitiesクエリをインラインで実行することになります。意見。

例えば：

次の2つのエンティティがある場合：

製品（[PK] ProductId、Title、Amount）

画像（[PK] ImageId、[FK] ProductId、ImageTitle、DisplayOrder）

強く型付けされた製品ビューがあり、プライマリ画像（表示順序が最も低い）を表示したい場合は、ビューで次のようなことを行うことができます。

@{
     Image image = (from l in Model.Image
                    orderby l.DisplayOrder
                    select l).FirstOrDefault();
}

これはデモンストレーション用の簡単な例ですが、確かにこれはMVCアーキテクチャに関連するルールを曲げ始めますが、一方で、コントローラーでこれを実行してから（天国では禁止）ViewBagまたはViewDataにジャムするのは確かに正しいでしょう犯罪の多くは、いくつかの異なる関連クラスを管理するのに苦労します。

以前は複雑なモデルのカスタムクラスを作成していましたが、時間がかかり、醜く、Entity Frameworkを使用すると、ビューをプライマリモデル（この場合は製品）としてすばやく簡単に定義でき、ポイントがわかりません。次に、Linqクエリを使用して、製品のすべての周辺コンポーネントを簡単に取得します。

他の人がこのタイプのシナリオをどのように処理するか知りたいです。

編集：

私もよく次のようなことをします：

@foreach(Image i in Model.Image.OrderBy(e => e.DisplayOrder).ToList())
{
   <img ... />
}
4

1 に答える 1

0

私は「モデルのカスタムクラス」の方法を採用していますが、時間がかかり、ありふれたものであることに同意します。そのため、このタスクに付随するhttp://automapper.codeplex.com/などのツールが作成されています。

全体的に、私はあなたと同じような気持ちを持っています。ドメインモデルをストレージとは無関係にし、ビューモデルのクラスをドメインモデルとは異なるものにするのが良いと言っているものを読んでから、ライブラリが実際に簡単な方法で「促進」しているように見えることを確認します（ドメインクラスのデータアノテーションはEFの流暢なインターフェースなどよりも単純になります）。

少なくとも私たちには選択肢があります！

モデルのバインドモデルデータをPOSTしてデータベースに保存する場合は、MVCモデルバインダーがすべてのフィールドを正しくバインドするように注意する必要があるという問題もあります。そうしないと、一部のデータが失われる可能性があります。ビューのカスタムモデルを使用すると、より単純になる可能性があります。

検証 MVCは、属性を使用して検証する方法を提供します。ビューモデルを使用する場合、ビュー固有であるため、そのようなアノテーションで自由に汚染できます（検証はビュー/コントローラーアクション固有である必要があります）。EFクラスを使用すると、それらのクラスを無関係な（場合によっては競合する）ロジックで汚染することになります。

于 2012-09-13T11:04:57.650 に答える