java - Value オブジェクトにはどのくらいのビジネス ロジックを含める必要がありますか?

Question

私が尊敬するメンターの 1 人は、単純な Bean は時間の無駄だと示唆しています。値オブジェクトには、有用なビジネス ロジックが含まれている必要があります。

また、そのようなコードは保守が難しく、すべてのビジネス ロジックを外部化する必要があると言う人もいます。

この質問は主観的であることを理解しています。とにかく尋ねる - より多くの視点からの答えを知りたい.

Answer 1

データとビジネス ロジックを組み合わせるという考え方は、カプセル化を促進し、内部状態を他のオブジェクトにできるだけ公開しないようにすることです。そうすれば、クライアントは実装ではなくインターフェイスに依存できます。「聞くな、聞くな」の原則とデメテルの法則を参照してください。カプセル化により、データの状態が理解しやすくなり、コードが読みやすくなり、クラスを分離しやすくなり、一般的に単体テストが容易になります。

ビジネス ロジックを外部化すると (通常は「サービス」または「マネージャー」クラスに)、「このデータはどこで使用されるのか?」などの疑問が生じます。そして「それはどのような状態になることができますか?」答えるのがずっと難しい。それはまた、オブジェクトに包まれた手続き的な考え方でもあります。これは、貧血ドメイン モデルにつながる可能性があります。

振る舞いを外部化することは、必ずしも悪いことではありません。たとえば、サービス層はドメイン オブジェクトを調整する場合がありますが、状態操作の責任を引き継ぐことはありません。または、入力フォームに適切にマップする DB への読み取り/書き込みを主に行っている場合は、ドメイン モデル (またはそれに伴う苦痛なオブジェクト/リレーショナル マッピングのオーバーヘッド) はまったく必要ないかもしれません。

転送オブジェクトは、多くの場合、ビジネス ロジックを公開することなく、呼び出し側レイヤーが必要とする最小限の状態情報を提供することで、アーキテクチャ レイヤーを相互に (または外部システムから) 切り離す役割を果たします。

これは、たとえば、ビューの情報を準備するときに役立ちます。ビューに必要な情報を与えるだけで、それ以外は何も与えないため、どの情報を表示するかではなく、どのように情報を表示するかに集中できます。たとえば、TO は複数のデータ ソースの集合体である場合があります。

利点の 1 つは、ビューとドメイン オブジェクトが分離されていることです。JSP でドメイン オブジェクトを使用すると、ドメインのリファクタリングが難しくなり、getter と setter の無差別な使用が促進されます (したがって、カプセル化が解除されます)。

ただし、多くの Transfer Objects を持つことと、多くの場合、多くの重複があることに関連するオーバーヘッドもあります。私が行ってきたいくつかのプロジェクトは、基本的に他のドメインオブジェクトをミラーリングする TO で終わります (これはアンチパターンと見なされます)。

Answer 2

それらをTransfer ObjectsまたはData transfer objects (DTO)と呼んだほうがよいでしょう。

以前は、この同じ j2ee パターンは「値オブジェクト」と呼ばれていましたが、これと混同されたため、名前が変更されました。

http://dddcommunity.org/discussion/messageboardarchive/ValueObjects.html

あなたの質問に答えるために、表示上の理由から必要な最小限のロジックのみを DTO に配置します。

さらに良いことに、データベース ベースの Web アプリケーションについて話している場合は、コアの j2ee パターンを超えて、HibernateまたはJava Persistence APIを使用して、リレーションの遅延読み込みをサポートするドメイン モデルを作成し、これをビューで使用します。

ビューで開いているセッションを参照してください。

このように、一連の DTO をプログラムする必要はなく、ビュー/コントローラーなどで使用できるすべてのビジネス ロジックを利用できます。

Answer 3

場合によります。

おっと、私は決まり文句をぼんやりさせましたか？

オブジェクトを設計する際の基本的な質問は、オブジェクトのデータを管理するロジックは、他のオブジェクトによって使用/消費されたときに異なるか、同じかということです。

さまざまな使用領域でさまざまなロジックが必要な場合は、それを外部化します。オブジェクトがどこに移動しても同じである場合は、クラスと一緒に配置します。

Answer 4

私の個人的な好みは、すべてのビジネス ロジックをドメイン モデル自体、つまり「真の」ドメイン オブジェクトに入れることです。そのため、データ転送オブジェクトが作成されるとき、それらはほとんどがドメイン オブジェクトの単なる (不変の) 状態表現であるため、ビジネス ロジックは含まれません。ただし、クローン作成と比較のためのメソッドを含めることはできますが、ビジネス ロジック コードの中身はドメイン オブジェクトにとどまります。

Answer 5

コロスが言ったこと。

値オブジェクト := 同一性が同一性に基づいていない、お金や日付範囲などの小さな単純なオブジェクト。

DTO := メソッド呼び出しの回数を減らすために、プロセス間でデータを運ぶオブジェクト。

これらは Martin Fowler によって提案された定義であり、私はそれらを普及させたいと考えています。

Answer 6

私は Panagiotis に同意します。ビュー パターンでのオープン セッションは、DTO を使用するよりもはるかに優れています。別の言い方をすれば、ビュー レイヤーからドメイン オブジェクト (またはその複合体) をトラフィックする場合、アプリケーションははるかに単純であることがわかりました。

とはいえ、HttpSession を永続化レイヤーの作業単位と一致させる必要があるため、実行するのは困難です。次に、すべてのデータベースの変更 (つまり、作成、更新、および削除) が意図的なものであることを確認する必要があります。つまり、ビュー レイヤーにドメイン オブジェクトがあり、フィールドが変更され、アプリケーション コードが意図的に変更を保存せずに変更が永続化されることは望ましくありません。対処すべきもう 1 つの重要な問題は、トランザクションのセマンティクスが満足できるものであることを確認することです。通常、1 つのドメイン オブジェクトの取得と変更は 1 つのトランザクション コンテキストで行われ、ORM レイヤーに新しいトランザクションを要求させることは難しくありません。とは難しいのはネストされたトランザクションであり、最初に開いたトランザクション内に 2 番目のトランザクション コンテキストを含める必要があります。

Java 以外の API がこれらの問題をどのように処理するかを調べても構わない場合は、Rails の Active Record を調べる価値があります。これにより、Ruby サーバー ページはドメイン モデルと直接連携し、その関連付けをトラバースできます。