2

サービス層を設計するとき、インターフェイス コントラクトでドメイン オブジェクトを使用する必要がありますか? 例えば：

public void registerUser(文字列ユーザー名、文字列 realName)

VS

public void registerUser(ユーザー ユーザー)

ドメイン オブジェクトは、クライアント コード内で構築する必要がありますか?それともサービス ファサードの背後で構築する必要がありますか?

私は EJB を使用しており、クライアントはローカルにデプロイされた Web アプリケーション、RMI クライアント、およびおそらく Web サービス クライアントです。

4

6 に答える 6

5

技術的には、どちらを使用しても問題はありません。XSD を介した Web サービスは、文字列などのプリミティブ型とユーザー クラスなどの複雑なオブジェクトをサポートできます。

では、クラスに 20 個の属性があり、ユーザーを登録するUserだけでよい場合はどうなるでしょうか。その特別なケースでは、最初のアプローチを使用することをお勧めします。これは、必要のない大きな XML ドキュメントの構築をクライアントに強制しないため、必要な帯域幅が少なくて済むからです。usernamerealName

もう 1 つのシナリオは、User クラスが JAXB 規則に従って複雑で高度にネストされた XML ドキュメントを生成することです。これにより、クライアントに対して複雑なメッセージが生成され、複雑なクライアント実装も生成される可能性があります。その場合は、1 つまたは 2 つのネスト レベルを持つ、より単純なバージョンのドメイン クラスを DTO として使用して、メッセージ交換を簡素化できます。

于 2012-05-21T01:23:15.090 に答える
1

私の意見では、一般にサービス層はドメイン オブジェクトを使用すべきではありません。ドメインはビジネス ロジック、ルール、およびワークフローを処理するものであり、サービスはそれにインターフェイスを提供します。

サービスレイヤーを設計する際の最もシンプルな原則は、「単一のユースケースを実現するサービスメソッド」です。(ユース ケースは、入力と出力の両方が適切に定義されたシナリオです)。

あなたのサンプルでは - registerUser(String username, String realName)- 完全にうまく見えます。サービスは、必要なすべてのドメイン オブジェクトをインスタンス化し、ビジネス オペレーションを開始します。同時に、サービス クライアントはビジネス ロジックの内部を認識しません (たとえば、ユーザー オブジェクトの構築などに固有のものがある可能性があります)。

于 2012-05-21T13:23:13.887 に答える
0

サービス層の一部としてドメイン オブジェクトを渡す方法は、はるかに単純でよりオブジェクト指向です。ユーザー入力値を処理し、関連するドメイン オブジェクトを構築することは、コントローラーレイヤーの役割です。

さらに、サービス層は、エンド クライアントが使用するAPIを記述します。サービス層がジェネリック型 (String、Maps など) で API を公開し始めると、問題が発生します。

アンチパターンである DTO の代わりに、ドメイン オブジェクトは、コントローラー レイヤーからサービス レイヤーに渡されるように装備されています。

于 2012-05-22T11:23:12.567 に答える
0

すべてのサービスで User オブジェクトを渡しても害はないようです。DDD (Domain Driven Design http://en.wikipedia.org/wiki/Domain-driven_design ) によると、これは非常に優れた方法であり、すべてのドメイン オブジェクトをプロジェクトのすべてのレイヤーで使用できるようにする必要があります。長期的には、典型的な Java EE プロジェクト (別名貧血ドメイン モデル) に通常欠けているオブジェクト指向のコードを作成するようになりますが、唯一の追加の推奨事項は、ビジネス ロジックをサービス内ではなくUser クラス内に保持することです。 .

于 2012-05-22T09:29:49.407 に答える
0

ドメイン オブジェクトは、クライアント コード内で構築する必要がありますか?それともサービス ファサードの背後で構築する必要がありますか?

ドメイン オブジェクトはサービス側で作成する必要があります。クライアントは、オブジェクトの作成に必要なすべてのパラメーターを渡すだけです。

オブジェクト構築の一般的なアルゴリズムは次のとおりです。

  1. パラメータを取得する
  2. パラメータを検証する
  3. 有効なパラメーターをオブジェクト コンストラクターに渡して有効なオブジェクトを取得する
  4. 有効な構築済みオブジェクトを永続化のためにリポジトリに登録します (必要な場合)

オブジェクトがクライアント側で作成され、サービスに渡される場合、いくつかの問題が発生します。

  1. クライアント側からのオブジェクトが正しくない状態である可能性があります (クライアント データは信頼できません)。
  2. オブジェクトの状態を検証する必要があります
  3. 既存のオブジェクトの検証は、検証ロジックの重複の可能性、プライベート フィールド値の検証時のカプセル化の損失の可能性、または場合によっては単一責任原則違反を意味します。
  4. 渡されたオブジェクトのプロパティ値をパラメーターとして使用して、サービスがオブジェクトを再構築する必要がある場合があります。
于 2015-05-23T15:46:37.223 に答える
0

私の意見では、ドメイン オブジェクトをファサード レイヤーから公開することは適切ではありません。サービスを使用しているクライアントは、ドメイン オブジェクトに依存しないでください。データ コントラクトを設計し、ファサード レイヤーから公開することをお勧めします。それらはデータを転送するためだけに使用され、それが DTO です。ドメイン オブジェクトは単なる DTO ではなく、いくつかの機能のないものを提供できることを考慮してください。また、ファサード層のサービスはシステムの使用法を公開します。これには、複数のドメイン オブジェクトの一部のコラボレーションが含まれる場合があり、ファサード層のメソッドの要件と利用可能なドメイン オブジェクトの間に適切なマッピングがない場合があります。また、ネットワーク パフォーマンス上の理由から、DTO とその構造についても考慮が必要になる場合があります。これらの考慮事項は通常、ドメイン オブジェクトの設計には意味がありません。

于 2014-02-10T10:53:13.870 に答える