51

これはおそらく古くからの質問だと思いますが、より良い方法は何ですか?アプリケーションのすべてのレイヤーでドメインモデルオブジェクトを使用し、JSPで値をそれらに直接バインドすることもできます(私はJSFを使用しています)。または、ドメインモデルオブジェクトをDAOまたはサービスレイヤーでDTOに変換し、軽量のDTOをプレゼンテーションレイヤーに送信します。

データベースを変更するとすべてのDTOが変更されるのに対し、どこでもモデルオブジェクトを使用するには、影響を受けるモデルオブジェクトを変更するだけでよいため、DTOを使用するのは意味がないと言われています。ただし、DTOの使いやすさと軽量性はそれを上回っているようです。

私のアプリはHibernateモデルオブジェクトを使用し、独自にカスタム作成されたモデルオブジェクトを使用していることに注意してください(つまり、DBセッションにバインドされず、常にデタッチされます)。上記のシナリオのいずれかが、厳密なモデルオブジェクトパターンにとってより有益ですか?Hibernateの使用は、LazyInitializationExceptionsなどに関して非常に大きなPITAでした。

私はさらに議論を進めることを期待してこの質問を編集しています(私がこれを正しく行っているかどうかはわかりません):

私がモデルオブジェクトで抱えている問題は、それらがまったく柔軟ではないということです。以下のコメントは、モデルオブジェクトがすべてのレイヤーで使用できるようにアプリケーションを設計する必要があることを示しています。なんで?ユーザーがばかげた機能の一部を望んでいる場合、私は彼らに「それはモデルオブジェクトでは機能しない」と言うことになっていますか?

単純明快で、モデルオブジェクトが機能しない場合があります。あなたが持っているかもしれません:

public class Teacher {
    List<Student> students;
    [tons of other Teacher-related fields]
}
public class Student {
    double gpa;
   [tons of other Student-related fields]
}

しかし、多分あなたはそのすべての情報を必要としないでしょう。必要なのは、教師の名前、今年教える生徒の数、およびすべての生徒の平均GPAを合わせたものだけです。その場合はどうしますか?完全な教師情報と生徒の関係を取得すると、コードは生徒のリストにカウントされ、内部のすべてのGPAの合計平均を計算しますか?これは、「String lastName」、「int numStudents」、および「doublecombinedGpa」を使用してDTOを作成するよりも手間がかかるようです。

これらについては決心しているように聞こえるかもしれませんが、モデルオブジェクトをすべてのインスタンスで完全にクリーンに使用できるアプリケーションではまだ作業していません。異常なユーザー要求を伴う通常の実際のアプリケーションは、そのようには機能しません。

4

9 に答える 9

37

アプリケーションの複雑さに大きく依存します。ドメイン オブジェクトをビュー レイヤーに混在させると、次の 2 つの影響が考えられます。

  1. ビューレイヤーで必要なものに対応するために、ドメインオブジェクトを変更したくなるでしょう
  2. ビューレイヤーには、ドメインオブジェクトが提供するものとビューが実際に必要とするものとの間の不一致によって引き起こされる余分な複雑さが含まれます。この複雑さを回避することはできないかもしれませんが、おそらくビュー レイヤーには属していません。

ドメイン オブジェクトが単純で、ビューが少ない場合は、DTO をスキップするのが最も簡単かもしれません。

一方、ドメイン モデルが進化して複雑になる可能性が高く、ビューが多数かつ多様になる可能性が高い場合は、ビュー固有のオブジェクトを用意することをお勧めします。MVC の世界では、ViewModel を使用することは一般的であり、私には非常に理にかなっています。

于 2011-09-27T15:40:59.003 に答える
8

ドメインオブジェクトへの別の投票。ドメイン駆動設計に関する限り、ドメインモデルが王様であり、可能な場合は使用する必要があります。アプリケーションは、ほとんどのレイヤー(バーインフラストラクチャレイヤー)がドメインオブジェクトを使用できるように設計する必要があります。

DTOは、オブジェクトをシリアル化する必要がある場合にのみ役立つと思います。有線または互換性のないアーキテクチャへの転送がない場合、私はそれらを使用しません。DTOパターンは、シリアル化をドメインオブジェクトから除外するのに役立ちます。UI /ドメインの相互作用はシリアル化を必要としないことを考慮して、それを単純に保ち、実際のオブジェクトを使用してください。

于 2010-04-21T03:32:25.497 に答える
7

DTOを持つことは、一般的にアンチパターンではないと思います。それらを使用する多くの人々とシステムがあり、あなたが得る利点は、ドメインモデルから独立して設計およびモジュール化できる分離されたビューレイヤーです。可能な場合はドメインオブジェクトを使用する必要があることに同意しますが、ビューレイヤーをドメインモデルに直接結び付けると問題が発生する可能性があるシナリオがあります。

ドメインオブジェクトのみをラップし、ほとんどの操作をそれらに委任するビューモデルで良い経験をしました。これにより、ビューとドメインレイヤーが分離され、ドメインオブジェクトの柔軟な構成が可能になりますが、IDEがサポートしているため、実装する作業はそれほど多くありません。委任パターン。

于 2011-12-20T17:56:07.570 に答える
3

ドメイン オブジェクトの送信に問題がある場合のシナリオ:

  1. 集約された情報または他のタイプの「計算されたフィールド」が UI レイヤー (たとえば Flex / GWT ) に送信される必要があり、ドメイン オブジェクトを台無しにしたくない場合があります。
  2. 循環オブジェクト グラフをシリアル化する必要が生じる場合があります (この例では、 Student に List 関係がある場合)。一部のプロトコルには問題があります。
  3. フレームワーク シリアライザー (flex の blazeDS / GWT シリアライザー) を処理するときの Hibernate LazyInitializationException

そのような状況では、それが明確な答えであるかどうかはわかりません

于 2010-07-10T19:44:55.507 に答える
2

私の意見では、すべてのレイヤーでドメイン モデル オブジェクトを使用してもまったく問題はありません。あなたは、すべての情報は必要ないと言いました。JSP では、必要なデータのみを使用してください。すべてのプロパティをフェッチするよう強制する人はいません。また、GPA、学生数などを取得するために、オブジェクトのプロパティに関連する計算を行う必要があるともおっしゃいました。3 つのオプションがあります。ドメイン モデル オブジェクトに合成プロパティを作成して、適切なデータを返します。そしてきれい。コントローラーまたはサービスレイヤーで計算を行い、適切なゲッターを介して公開します。または、すべてを JSP 内で処理します。とにかくデータを取得/コンパイル/ラングリングする必要があるので、DTO を使用してさらに複雑にする必要はありません。

さらに、各 DTO を使用して、a.) 維持する必要がある追加のクラス、および b.) DTO を構築して設定するクラスのどこかに少なくとも 1 つの追加メソッド (DAO、ファクトリ メソッドなど) を作成します。 . メンテナンスの増加 = 6 か月後の開発者の不満。

したがって、DTO に対する私の主張があります。私はそれらを使用しますが、速度やメモリ使用量を本当に最適化する必要があり、完全なドメイン モデル オブジェクトをハイドレートするコストが高すぎる場合など、特定のシナリオでのみ使用します。Web サービスは、私が DTO を好んで使用する好例です。

于 2013-04-10T06:00:00.957 に答える
0

クラスの動作またはその内部メソッドは、その動作に関係のないレイヤーに公開しないでください。動作ではなく、データを転送します。ドメイン内でドメイン オブジェクトを使用します。Web は制御されたドメインではなく、UI 開発者はドメインの動作に関心を持つ必要はなく、データだけに関心を持つ必要があります。

ドメインはカプセル化する必要があり、ドメインの状態に関係のない人による変更から保護する必要があります。

リーク動作は最善の習慣ではありません。

小規模なプロジェクトの場合は、正しい原則で構築してください。そうすれば、どのように行うかだけでなく、なぜ行うのかを常に心に留めておくことができます。

于 2015-03-23T17:34:57.920 に答える
-1

ここでまず考えるべきは、新しいレイヤーを導入するためのコストだと思います。DTO を例にとると、マッピングが必要になります。誰かが言ったように、翻訳は悪であり、可能な限り避けるべきです。

一方で、一般的にやってはいけないことはほとんどないと思います。すべての DTO が悪だと言う人は間違っています - それは常にユースケースに依存します! 彼らは本当に正当化されていますか?

最後に、私は個人的に、ドメイン オブジェクトをビュー自体に任せるべきだと考えています。改札の統合がどのようなものか想像してみてください。しかし、Spring MVC を例にとると、ドメインはおそらくアプリケーション層にとどまります...

于 2013-08-18T07:37:40.407 に答える
-4

DTOは現在、アンチパターンと広く見なされており、アドバイスは通常「絶対に避けてください」です。

HibernateのようなORMフレームワークの主な利点の1つは、すべてのレベルでドメインオブジェクトを使用でき、実際にはDTOを必要としないことです。もちろん、注意点は、遅延フェッチを使用する場合、熱心に使用する場合など、これらの関係についていつか考えることに専念する必要があるということです。

于 2010-04-21T03:22:10.313 に答える