4

2 つのサービス クラスがあるとします。

UserService
ProductService

ProductService クラス内に UserService を注入すると問題がありますか?

public class ProductserviceImpl implements ProductService {


  @Autowired
  UserService userService;


  @Override
  public void someThing() {
      ..
      userService.otherThing(..);
      ..
  }

}

別の方法として、UserService と ProductService の両方を注入する別のクラスを作成できることはわかっていますが、このクラスの名前を考え出すのは非常に難しいです :) SOA の世界でこれらのタイプのクラスの名前はありますか?

4

5 に答える 5

2

1）ProductServiceクラス内でUserServiceを注入するのは間違っていますか？

これ自体には何の問題もありませんが、次の点に注意してください。

  • あるクラスがやりすぎの方向に向かっている可能性があることに注意してください（ここでは、ProductService）
  • 循環依存関係を導入しないように注意してください（UserServiceもProductServiceに依存しないようにする必要があります）
  • 依存関係を具象クラスではなくインターフェースに配線することにより、密結合を制限します（ここでは、UserServiceImplの代わりにUserServiceを自動配線しています。これは良いことです）

2）このタイプのクラス（UserServiceとProductServiceの両方を注入する）の名前はありますか？

はい、前述のように、メディエーターパターンがこれを説明しているように見えるため、このクラスをメディエーターと呼ぶことができます。

低レベルのサービスと高レベルのサービスの両方を使用でき、低レベルのサービス（ProductService、UserService）を高レベルのサービス（PurchaseOrderServiceやPurchaseOrderMediatorなど）に注入できます。あるいは、この特定のケースでは、製品サービスをUserServiceに依存する単一の高レベルサービスと考えることができます。その時点で、ビジネスロジックとアプリケーションのコンテキストでどの構成がよりまとまりがあるかが重要になります。

于 2012-10-18T17:21:23.607 に答える
1

私にとって、サービスを別のサービスに注入することは問題ありません。あなたが言ったように、それがサービスとSOAのポイントです。

サービスは、最終的な結果を得るために互いに助け合うことができます。その上、JB Nizet が語ったように、循環依存関係がなければ問題ありません。

于 2012-10-17T20:57:07.053 に答える
0

あなたが説明しているのはメディエーターパターンと呼ばれています。

ところで、SOAとは何ですか？

于 2012-10-17T20:53:28.713 に答える
0

あなたが説明しているのはオブジェクト指向の統合であり、おそらくSOAの統合ではありません。循環依存を取得する可能性がある（そして回避する必要がある）という事実は、それを示しています。

サービスが他のサービスJavaレベルインターフェイスを知っている場合は、密結合を導入する大きなリスクもあります。たとえば、ユーザーサービスからの返品タイプは何ですか？それはユーザーサービスに属するさらに別のインターフェースですか？製品サービスのコードでそれを渡しますか？

于 2012-10-23T19:57:42.637 に答える
0

あなたが言及したように、春を使用してあるサービスを別のサービスに注入すると、2つのサービスは使用されるインターフェースの範囲内でのみ結合されます。

さらに分離が必要な場合は、メッセージを使用して 2 つのサービス間をやり取りすることを検討してください。

メッセージは、スキーマを持つ値オブジェクト/xml のように強く型付けすることも、HashMap のように弱く型付けすることもできます

弱く型付けされたメッセージはデカップリングを増加させる可能性がありますが、それはあなたとあなたのクライアントがコンパイル時のチェックを放棄し、デバッグの問題が実行時に面倒になることを意味します

于 2012-10-18T08:44:08.643 に答える