asp.net（webapi + mvc）プロジェクトでは、BLLに公開インタフェースとして多くのdtoがあります。また、私のビューモデルのほとんどは適切なdtosと同じです。DTO vs VM - 使用するかどうかは？
スマートブックはこの種のモデルを分離する必要があると教えていますが、プロジェクトではこの解決策のメリットはありません。多くの愚かな間違いで無駄なコードが数百に過ぎない。
したがって、DTOを可能であればビューモデルとして使用するのは正しいですか？このソリューションのプラスとマイナスの影響は何ですか？
データ転送オブジェクトは、論理境界と物理境界の間で転送されるデータのサブセットまたはスーパーセットに過ぎません。彼らはの動作を提供できません。それらは単なるデータです。
反対側では、ビューモデルは、特定のビューの論理側であるため、データとビヘイビアが混在しています。
DTOとVMはさまざまなユースケースをカバーするパターンなので、無駄なデータや動作が発生し、不要な依存関係を追加できます。
たとえば、ドメインとアプリケーション層の両方でDTOを使用できます。単一のクラスでDTO概念とVM概念の両方を使用している場合は、ドメインプロジェクトを強制的にビルドできるようにUIライブラリへの参照を追加することができます。私はできるだけこれを避けるでしょう。
また、あなたはDRY滞在するために、ここであなたを支援することができ継承、（自分を繰り返さない）と呼ばれるオブジェクト指向の概念があります知っている：あなたができる、要約
public class Base {}
public class Dto : Base {}
public class ViewModel : Base {}
は、継承を持つDTOモデルとビューモデルの両方に共通することを共有し、コードの繰り返しを避けます。
彼の詳細な答えは、MatíasFidemraizerです。それに加えて私はいくつかの実用的で必要なアプリケーションを見つけました。
別個のエンティティとしてVMを使用する場合、追加の柔軟性のポイントを追加します。最も一般的なケースは、わずかなフォーマットやフロントエンドデータの構造の変更です。 2番目のケース - あなたのVMはいくつかのDTOオブジェクトから情報を構成することができるので、bllコードを変更せずに、または最小限に抑えることができます。それがS.O.L.I.D.働く
しかし、最も有用な部分は単体テストです。あなたのDTOオブジェクトはシンプルでクリアなので、あなたのbllをもっと簡単にテストできます。間違いをマッピングすることも珍しくありません。
'DTO' **は**基本クラスとしてはいかがですか？単純なキャストVMからベースクラスへのDTO（何もコピーする必要はありません）を生成します。 – Sinatr
@Sinatr私は先住民族なので、次のような宣言を真実にしたいとは思わないでしょう： 'if（vm is Dto）'： –