4

パターンの使用については、必要な場合にのみ多くのことを読みました。私は現在、リポジトリとサービスのパターンを実装した非常にシンプルなアプリを作成しています。現在、DTOを使用してドメインオブジェクトをビューに渡すかどうかについて議論しています。これは単一ページのアプリケーションです。

モデルでDTOクラスを作成し始めましたが、それでもDTOクラスがどのようなメリットをもたらすのか理解できません。理由もなくすべてを複製しているような気がします。

DTOを使用するのが適切なのはいつですか？どの時点でそれは必要または有益になりますか？どんな例/サンプルも素晴らしいでしょう。

4

1 に答える 1

9

モデルでDTOクラスを作成し始めましたが、それでもDTOクラスがどのようなメリットをもたらすのか理解できません。

その場合、この状況では、メリットが得られない可能性があります。最も単純なアプローチに固執することが常に最善であるため、不必要に複雑さを追加しようとしている可能性があります。

DTOは、複雑なドメインオブジェクトを必要とせずに、フラットなデータを渡す必要がある場合に便利です。可能であれば、ビューをビジネスオブジェクトに直接バインドすることが望ましいと思われます。他に何もない場合は、ビジネスオブジェクトが使用シナリオに沿っていることの健全性チェックを提供します。実際、これは、ビジネスオブジェクトに焦点を当てたCSLAフレームワーク（とりわけ）によって提唱されたアプローチです。

ドメインオブジェクトをDTOに変換する最も一般的なシナリオは次のとおりです。

  1. 外部サービス（それ自体が内部ドメインオブジェクトと整列していない）への抽象化された依存関係があり、サービスインターフェイス自体を非常に単純にしたい場合。サービスレイヤー内ですべての変換を行うのではなく、レイヤー自体にDTOを使用させ、2つの間に変換レイヤーを構築します。
  2. シリアル化されたオブジェクトをAJAX呼び出しを介してJavaScriptに返し、ドメインオブジェクトの余分なオーバーヘッドをすべてネットワーク上に行きたくない場合。JavaScript自体をシンプルに保ち、外部ネットワーク接続を介して不要なデータを送信しないなど。
  3. さまざまなドメインオブジェクトのデータの合成を使用しているが、そのスーパーセットを使用していないビューがある場合。場合によっては、これは、このビューが独自のドメインオブジェクトに値するユースケースを表していることを示している場合があります（おそらく、他のオブジェクトの複合、または関連するすべてのオブジェクトは、より小さな非集約ルートオブジェクトの複合である必要があります）。 、このシナリオには注意してください。ただし、中間のDTOを作成するだけで、コードが少し単純でクリーンな状態に保たれる場合があります。

重要なのは、データのある形状から別の形状への変換にあると思います。サービス、コントローラー、またはビューで多くの変換が行われている場合、おそらくその変換は、それ自体のオブジェクトに値するのに十分な大きさのコンポーネントです。本当に、関心の分離がすべてです。経験則として、コードの一部が「ある目的のためにデータを再形成し、その目的を達成する」場合、そのコードは2つのことを実行します。それを2つのコードに分割する方が良いかもしれません。DTOは、これら2つの通信方法です。

志を同じくするオブジェクト間を変換する際に多くの「足場」コードを支援できるツール（AutoMapperなど）があります。

于 2013-03-01T01:44:27.650 に答える