ViewModelを作成すると冗長性が生まれませんか?ある意味で、私は自分のドメインモデルを持っており、そこからのデータをビューに表示する必要があります。そこで、ViewModelsを作成し、それにDataAnnotationsを追加して、ビューに表示します。この時点で、ほぼ同じデータを持つ2つのオブジェクトがあります。
4 に答える
他の人がすでに言ったように、最も些細なアプリケーションだけが、ドメインモデルをビューに直接渡すことで逃げることができます。それでも、多くの理由から、それはまだ良い考えではありません。
ビューの要件は、データモデルの要件とは異なります。たとえば、ビューでは必須であるが、vieモデルではnull許容のフィールドがある場合があります。`[Required]'属性を追加すると、モデルはこのフィールドをnull不可と見なします。
ただし、ビューでドメインモデルを使用しない最大の理由は、セキュリティのためです。MVCを使用すると、任意の値を投稿できます。デフォルトのモデルバインダーは、投稿した値をモデルにプラグインします。つまり、IsAdminフラグがあり、誰かがIsAdminの真の値を投稿した場合、変更を保存するとモデル、誰かが管理者になりました。
Webセキュリティの最初のルールは、ユーザーからの入力を信頼することではなく、ビューモデルをビューに直接渡すことは基本的にデータのサニタイズをあきらめます。
はい、それは冗長性の一形態です。ただし、他の目標を達成するには、冗長性が必要になることがよくあります。モデルの場合、ビューモデルとドメインモデルをこのように分離することで、ビューとデータストア間の分離されたセットアップを実現できます。また、ViewModelsがドメインの正確なコピーであるということはめったにありません。
つまり、どちらも他方に影響を与えることなく変更できます。これが役立つ場合があります。テーブルのデータ型を変更するために、Webアプリケーションのデプロイを要求する必要はありません。
したがって、要約すると、冗長性はありますが、システムがこの冗長性の恩恵を受けるのに十分複雑であるかどうかに関する設計上の選択です。
いいえ、ViewModelの使用には独自の目的があります。ビューにドメインモデルからの2つ以上のエンティティがあり、ViewModelがない場合の状況を考えてみましょう。データをどのように整理しますか?ビューに必要なデータは、ドメインモデルとまったく同じではなく、情報が少ない場合や多い場合があり、ビューをレンダリングする前にドメインからのデータを前処理する必要がある場合があります(たとえば、フォーマットの日時はクライアントの文化によって異なります)。
さらに、ViewModelは、WebUIをドメインレイヤーから切り離すのに役立ちます。ドメインモデルのエンティティは、データ表現(ビューモデルの唯一の目的)だけでなく、ビジネスルールを模倣する操作も備えているため、必要のないUIレイヤーにドメイン知識をあまり公開したくない場合があります。知るために。
99%の場合、ViewModelsは冗長性をもたらしません。
私の頭に浮かぶ唯一の1%は、貧血のドメインモデルとページを使用した単純なアプリケーションであり、ページ上に1つのモデルしか表示されません。これは、コンテンツ管理ページに固有のものです。
その他の場合:
1)ViewModelsは複数のドメインモデルからの情報を結合します
2)ドメインモデルにドメインに固有のロジックがあります
3)DataAnnotationsなどのビュー固有のメタ情報をドメインに混在させることはお勧めできません