3

私はMVCフレームワーク（ASP.NET MVC2 / 3 / Razor）を使用して数か月しか経っていないので、本当に楽しんでいますが、ビューモデルの標準を理解するのに苦労しています。私のプロジェクトには、Modelsフォルダー（データモデルが含まれています-Linq DBML、Repository [ies]、Extensionメソッド）とModels/ViewModelsフォルダーがあります。私のビューモデルは通常、再利用可能なクラスであり、通常、特定のビューにアクセスする必要があるLINQオブジェクトまたはオブジェクトのコレクションの単純なget/setプロパティが含まれています。

今私が抱えている問題は、ビューモデルをいつ作成するかを理解することです。私の目標は、特に編集アクションの場合に、LINQオブジェクトをビューモデルとしてできるだけ頻繁に使用することです。私の問題は、表示目的でのみ使用したい他のデータがある場合はどうなりますか？ViewData / ViewBagコレクションを使用するのは好きではありません。これらのメンバーにアクセスするには、コレクションアイテムのキーに関する知識が必要です（デザイナー/フロントエンドの人が「推測」するのは簡単ではありません）。また、ビューごとにViewModelを作成するというアイデアも好きではありません。これは、不必要に厄介なコードのように見えるためです。

たとえば、ある従業員のデータモデルがあり、その従業員とは関係のない情報を表示したいとします。たとえば、サイト統計、動的メニューなど、データベースから取得できると思われる情報をすべて表示します。/ Employee / Editアクションを渡す必要があるモデルは何ですか？残りのViewData[]の束を持つEmployeeオブジェクト、またはカスタムEmployeeView？

ゴールドスタンダードはありますか？私は何が欠けていますか？私が調べなければならないことをあなたは何を変えていますか？前もって感謝します！

4

3 に答える 3

3

エンティティクラスをビューモデルとして直接使用することはありません。私は常に、そのビューのデータを含むビューごとにビュー固有のモデルを作成します。AutoMapperを使用して、ビューモデルとエンティティモデルの間をマッピングし始めました。ToViewModel<TEntity,TViewModel>()これは、標準マッピングを処理するためのメソッド（automapperを呼び出すだけ）とカスタムマッピング用の特殊なマッピングメソッドを備えたModelMapperクラスを介して仲介します。特に、ビューモデルからのエンティティの作成と更新をサポートします。

于 2011-05-20T21:55:43.907 に答える
2

ここでは、次の3つの名前を付けました。

  • サイト統計
  • 動的メニュー
  • 他に何でも[...]データベースから来るかもしれません

その3番目のポイントは罠です。データベースに何かがあるからといって、それがドメインモデルの一部であるとは限りません。

ナビゲーションはデータベースに基づいている場合があります。また、サイトマップに含まれているか、アプリケーションにハードコードされている可能性があります。これは実際にはアプリケーションデータではなく、アプリケーション構成です。アプリケーションデータベースに保存している場合、それは問題ありませんが（実際にはそうではありません）、モデル自体の一部ではありません。

同様に、サイト統計は通常データベースに保存されますが、別のデータベース、具体的には分析データベースに保存されます（そして多くの人はこれをGoogleに「アウトソーシング」するだけです）。繰り返しになりますが、これらは一種のデータですが、モデルではありません。

アプリケーションに意味を持たせたい場合は、これらの懸念を概念レベルで分離する必要があります。ナビゲーションは、マスターページ/レイアウトで実行されます。これには、それを機能させるために必要な動的コードが含まれます。これは純粋なビューロジックです。モデルにリークさせないでください。現在使用されている実際の機能に付随する懸念事項については、通常はViewData/ViewBagを使用することをお勧めします。

ここで、実際にはアプリケーションデータである他の種類のビューデータがあると仮定します。原則として、ビューはモデルに直接接続されることになっています。つまり、「MVC」の意味ですが、実際には、それは単なる再です。思いがけない「正規データモデル」のアイデアの実装。ドメインとプレゼンテーションは別々の関心事であり、そのため、異なるコンテキストモデルを意味します。後者の場合、それはビューモデルです。

私が最初にMVC作業を始めたとき、私はビューモデルも使用することに抵抗がありました。しかし、私がそのアイデアに慣れた後、それが本当に唯一の持続可能な解決策であることに気付きました。特に、「モデル」がデータベース自体の薄いラッパーである場合はなおさらです。ビューとデータはさまざまな方法でさまざまな速度で変化します。バグやリグレッションの絶え間ない流れについて心配したくない場合は、2つの間にある程度の絶縁が必要です。マッピングレイヤーを作成し、それを1日と呼びます。

この時点で、必要かどうかに関係なく、ビューごとに異なるビューモデルを作成することにしました。最初は、モデルクラスのカーボンコピーに過ぎないかもしれませんが、基礎となるモデルをいじくり回さなくても、いつでもどのような方法でも微調整できることを意味します。その逆も同様です。 テレビが言うように、最初のビューモデルはAutoMapperを使用して簡単に生成でき、おそらく30秒の時間がかかります。

ビューモデルを使用するだけで、最終的にツールがビューモデルの自動生成をサポートすることを期待します。

于 2011-05-20T22:14:36.890 に答える
0

従業員を編集するためのページを作成するが、あなたが言及したもの（サイト統計/メニュー）も表示する場合、それらを部分ビューまたはレイアウトファイルに配置してみませんか？

于 2011-05-20T22:03:47.813 に答える