このブログ投稿によると、 「ModelMetadata オブジェクトは、主に System.ComponentModel および System.ComponentModel.DataAnnotations 名前空間の属性から取得したデータで構築されます。」
Model オブジェクト ( DisplayFormatまたはUIHint )に UI ヘルパー属性を配置することで、Model と View を結合していませんか?
3 に答える
9
そう信じる。個人的には、モデルを完全に UI にとらわれずに保ち、View でモデルを表す ViewModel を作成します。次に、すべての注釈をこれらの ViewModel に割り当てます。
違反は、基本的にモデルでビューの動作を定義しているため、モデルを再利用する能力が制限されるという事実に起因すると思います。
于 2011-08-17T15:27:21.143 に答える
0
これは、「結合」をどのように定義するかに大きく依存します。ある意味で、ビューはすでにモデルに「結合」されています。ビューは、モデルが定義するのと同じプロパティを使用します。問題は「結合」ではなく、「何を」「どのように」ということです。モデルは何を（表示する必要がありますか）記述します。どのように（それを行うか）を定義するのはビュー次第です。この原則に厳密に従う場合は、UIヒントを破棄する必要があります。
より実用的にしたい場合は、これらの属性によってビューが単純化されることがあります（複雑になりすぎることがよくあります）。だから、それはあなた次第です。
モデルを再利用可能にしたい場合（ほとんどの場合、これは良い考えではありませんが、ここでは独断的にはなりません）、アプリケーション全体で一貫している属性のみを使用するようにしてください。たとえば、すべての浮動小数点数を同じ方法で表示する場合は、ビューに何度も入力して退屈な詳細で汚染するのではなく、モデルにDisplayFormat属性を配置するのが理にかなっています。
私はメインビューに一般的な構造を配置し、詳細をパーシャルに委任する傾向があります。UIHint属性は非常に役立ちます。それをカップリングと呼びますが、そのメリットは非常に大きいです。
于 2011-08-28T11:24:51.760 に答える
0
そう思います。
ブラウザーとサーバー間の情報交換を表す特定のビュー モデル クラスを作成します。モデルの状態が有効な場合は、値をコピーするか、それらの値を使用してドメイン メソッドを呼び出します (これが Models フォルダーの目的です)。ドメイン エンティティに MVC 固有の属性を設定したことはありません。
経験則として、MVC について何も知らない別のアセンブリにエンティティを保持します。
MVCアクションメソッドでドメインエンティティを公開することに注意してください...モデルバインダーはあなたに悪い冗談を言う可能性があります:D たとえば、クラス「アカウント」があり、プロパティ「IsAdmin」があり、このエンティティを登録フォームで、ユーザーが GET 文字列または POST ペイロードで任意の「IsAdmin=true」パラメーターを渡そうとする可能性があり、MVC モデル バインダーがそのプロパティをモデルに設定します...そしてコードはおそらくその情報を保存しますデータベースで。
したがって、ビューモデルに注意を払うことは非常に重要だと思います。
ViewBag のようなこのすべての「動的」なものを使用して、独自の LINQ エンティティをアクション メソッドのパラメーターにすると、すべてが非常に簡単になることを知っています...しかし、セキュリティを見落としてはなりません。必要な情報だけがドメインに届くようにします。
乾杯。
于 2011-08-26T17:01:29.960 に答える