web-dev-qa-db-ja.com

MVCモデルオブジェクト、ドメインオブジェクト、DTOの違いは何ですか

MVCモデルオブジェクト、ドメインオブジェクト、DTOの違いは何ですか?

私の理解は:

MVCモデルオブジェクト:

対応するビューで表示されるデータをモデル化します。ドメインオブジェクトに直接マッピングしない場合があります。つまり、1つ以上のドメインオブジェクトからのデータを含める場合があります。

  1. クライアント側
  2. ビジネスロジックが含まれる場合があります。例えば。検証、計算されたプロパティなど
  3. 永続性に関連するメソッドはありません

ドメインオブジェクト:

Reservation、Customer、Orderなどの問題ドメイン内の実世界のオブジェクトをモデル化するオブジェクト。データを永続化するために使用されます。

  1. サーバ側
  2. ビジネスロジックなし

DTO(データ転送オブジェクト):

レイヤーが別のプロセスにあるときに、レイヤー間でデータを転送するために使用されるオブジェクト。 DBからクライアントアプリへ。複数のドメインオブジェクトに対応するデータをフェッチするときに、複数の呼び出しではなく、回線を介した単一のトランザクションを許可します。 DTOにはデータとアクセサメソッドのみが含まれ、ロジックは存在しません。データは特定のDBトランザクション用であるため、1つ以上のドメインオブジェクトからのデータが含まれている可能性があるため、ドメインオブジェクトに直接マップされる場合とされない場合があります。

  1. レイヤー間で渡されるときにサーバー側とクライアント側の両方で使用されます
  2. ビジネスロジックなし
  3. 永続性に関連するメソッドはありません

だから、質問:

  1. 上記の理解は正しいですか?重要なポイントがありませんか?

  2. モデルオブジェクトが追加のビジネスロジックを必要としないと仮定して、MVCモデルとしてドメインオブジェクトを使用しない理由はありますか?

  3. Modelオブジェクトが追加のビジネスロジックを必要としないと仮定して、MVCモデルとしてDTOを使用しない理由はありますか?

62
Timothy Mowlem

ドメインオブジェクトとモデルオブジェクトは基本的に同じであり、ビジネスロジックが含まれる場合があります。実装に応じて、ビジネスロジックをモデルからサービスクラスに削除した場合、ドメインとDTOオブジェクトは同等になる場合があります。

多くの場合、DTOの重要なバリアントはビューモデルです。これは、ドメインモデルとビューの間でデータを転送するためだけに使用されますが、ビューモデルにはロジックが含まれている場合があります。

16
ProfK

ドメインとDTOを「モデル」オブジェクトにすることもできます-「顧客」ドメインオブジェクトの詳細を表示するビューを作成できます。

ドメインオブジェクトは、ドメインエンティティのプロパティを強制するビジネスロジックを持つことができます。検証はそのようなケースの1つです。ドメインオブジェクト自体には永続性に関連するメソッドは含まれていませんが、永続性をサポートするメタデータ(注釈など)を持つことができます

pOJOプログラミングモデルでは、ドメイン、DTO、およびモデルオブジェクトと同じオブジェクトを使用できます。基本的に、1つのレイヤーにのみ適用され、他のレイヤーには適用されない無関係なインターフェイスは実装されません。

8
kartheek
A DTO = is an object that carries data between processes.

しかし、最も興味深い部分は、独自のデータの保存と取得を除いて、動作がないことです!!!

MVC方法論に固執する...

Domain = subject of your entire application.

Model = contains the (programming languages objects : EX: C# objects) to make up the universe of your application.

明らかに動作とプロパティを持つことができます(DTOとの違いを参照)。

多くの場合、アプリケーション(軽量アプリケーション)には1つのモデル(モデルがまさにドメインである場合)を含めることができます。別のモデルは、まったく異なるオブジェクトタイプであり、別のモデルを処理しています。両方とも、この場合はドメインの一部であり、「ドメインモデル-オブジェクト」という名前が付けられています。

うまくいけば、この答えは網羅的であり、あなたにとってすべてが明確になるでしょう!

3

ほとんどのオブジェクトの定義は、オブジェクトの使用場所に基づいてさまざまです。

Model:は、クライアントまたはサーバーオブジェクトを使用するための一般定義です。

  1. _Model View_:は、ほとんどの場合clientで使用されるオブジェクトです。
  2. _Domain Object_:はserverおよび_transfering data to the database_で使用されるオブジェクトです。
  3. Data Transfer Object(DTO)あるオブジェクトから別のオブジェクトにデータを転送する、特に_API Call_でデータを取得する場合(例:apiでGETメソッドデータを取得するための呼び出しは、データベースモデルをクライアントに提供しないでください。この目的のために、dto)を使用します。

注意:_the definitions are true most of the time_ですが、状況によっては実用的ではありません。

1
Sina Lotfi

1)いいえ、ViewModelの定義です。 MVCモデルオブジェクトとドメインオブジェクトは両方とも同じです。
2)ドメインモデル(オブジェクト)は常に存在し、ビジネスロジックはオプションです
3)ドメインオブジェクトにビジネスロジックがない場合、自動的にDTOになります。

1
palash140

私の主張(大短編)は次のとおりです。

(MVC)モデルオブジェクト:

  • 何らかの使用状況でいくつかのことを表します。 PersonEditModelPersonViewModel、または単にPersonModel
  • ビジネスロジックがない
  • 検証ロジックなどの対象になる場合があります。
  • あるアプリケーション層から別のアプリケーション層にデータを提供するために使用されます。 MVCコントローラー<-> MVCビュー

ドメインオブジェクト:

  • いくつかのビジネスオブジェクト(問題領域の実世界のオブジェクト)を表します
  • ビジネスロジックを持っています
  • 無効なオブジェクトの状態を許可しない、オブジェクトの状態を適切に変更するメソッドがあります
  • 関連するビジネスロジックをカプセル化するために使用
  • データを永続化するために使用する必要はありません(または使用すべきではありません)

DTO(データ転送オブジェクト):

  • modelオブジェクトに似ていますが、フラットな構造が必要です
  • 単純なタイプのプロパティ/フィールド(文字列、数値、日付時刻、ブール値)のみ
  • アプリケーションの境界を越えてデータを転送するために使用されます。 WebサーバーとWebブラウザーの間
1
owerkop