Modelとまったく同じViewModelを追加することをお勧めします

ソリューションに次のレイヤーがあります。

1. App.Domain
2. App.Service
3. App.Core（これをApp.DataLayerと呼ぶかもしれません）
4. App.Web

ソフトウェア設計パターンは私の質問ではなく、次のモデルがあります Domain

public class Foo {
    public int Id {get;set;}
    public int Name {get;set;}
    public int Value {get;set;}
}

ビュー（たとえば、ホームページ）でこのモデルを使用しId, Name & Value、さらにを使用したいので、ViewModelを作成する場合は、次を追加します。

public class FooViewModel {
    public int Id {get;set;}
    public int Name {get;set;}
    public int Value {get;set;}
}

だから、それは良いアイデアですか？または単に？のFoo代わりに使用しFooViewModelます

これは最初はDRYルールに違反しているように見えるかもしれませんが、何か異なることをしたり、独立して変更できる場合、「類似した、さらには同一のコード」は必ずしも「繰り返し」ではないと主張します。また、ビューモデルの場合、コードは「クライアント」が見るものを定義します。必ずしもビジネスが話すエンティティやオペレーションではありません。そのため、多くの場合、「偶然同一」のようなモデルをクライアントまたはインターフェイスに公開しています。ビジネスルールとビジネス用語、またはエンドユーザーの用語を互いに独立して変更できます。

だから、私はあなたに質問を返します。ドメインが変更された場合、「バージョン1」クライアントが古いインターフェースを引き続き使用することは許容されますか？「コアビジネスルール」の一部ではない用語や操作をインターフェイスで公開することはありますか？およびその逆？

ビューの「機能」が厳密に基礎となるドメインモデルを明らかにすることである場合、そういう質問を念頭に置いて、はい、これはDRY規則に違反しているように見えます。

_{また、モデルの変更に伴ってより自然に変化するビューを公開することは、メンバー属性とリフレクションを使用する一部の言語でも実現できます。（または他の巧妙な偉業を通しての繰り返しが少ない ...しかし、「賢さ」はしばしば、あなたを免れる繰り返しを正当化することに失敗します。）}

Fooインスタンスという1つのプロパティのみを含むビューモデルがあります。そうすれば、Fooが変更されてもビューモデルが自動的に変更を認識し、ビューモデルがモデルに直接結び付けられることはありません。その定義に従ってDRYに違反することはありません。

明日、Fooだけでなく他の何かを表示するビューが必要な場合は、新しいプロパティを追加するだけで、ビューモデルの意図が明確になり、Fooなどが含まれます。 Fooのプロパティと、関連のない他のプロパティの混合。

私はあなたのビューモデルをFooViewModelとは考えないでしょう、私はビューが何を表示することになっているのかという観点から考えます。Fooを1つだけ表示する場合、ビューモデルには1つのプロパティ、Fooが含まれます。

それを明確に説明したかどうかはわかりません。そうでない場合はお知らせください。起きているときに書き直します。

FooViewModelこのように使用すると、DRYプリンシパルに違反することになります。変更する必要がある場合は、変更するFoo必要もありますFooViewModel。Fooビューのモデルとして単純に使用する方が良いと思います。Fooからのものやその他のものを表示する必要がある場合は、ビューモデルを検討します。たとえば、あなたからいくつかの情報をレンダリングする必要があると言うFooともからBar。