1

私は自分のサービスのいくつかについて考えていました。それらのいくつかは次のようになります。

@Service
public class UserService {

   @Autowired
   UserDao dao;

   @Autowired 
   OtherService1 serv1;
   @Autowired 
   OtherService2 serv2;
   @Autowired 
   OtherService3 serv3;
   ....



}

私は考えていました..他のサービスを単一のサービスに自動配線するというこの概念がかなり一般的である場合、「マスターサービス」を作成してみませんか?

@Service
public class MasterService {


   @Autowired 
   OtherService1 serv1;
   @Autowired 
   OtherService2 serv2;
   @Autowired 
   OtherService3 serv3;
   ...
   @Autowired 
   LastService servN;


}

このサービスをすべてのサービスに自動配線します。

@Service
public class AnyService {

   @Autowired 
   MasterService masterSevice;
}

このようにして、サービスごとに多くのサービスを用意する必要はありませんが、すべてを支配するのは 1 つのサービスだけです..

2 つの疑問が生じます。

1) masterService にはすべてのサービスが含まれているため、インジェクションにループがあります。解決できますか？

2) 質問 1 の答えが「はい」の場合 - この「masterService」は適切な方法ですか?

4

4 に答える 4

2

1) Spring は、多くの場合、特にコンストラクター インジェクションを使用しない場合に、依存ループを処理できます。

2) それにもかかわらず。このデザインは絶対に避けるべきです。これは、優れたアーキテクチャの多くの原則を破っています。

  • コンポーネントは、必要な数の他のコンポーネントにのみアクセスできるようにする必要があります。デメテルの法則
  • 関心事の分離。サービスは、ビジネス ロジックとプレゼンテーションを同時に処理するべきではありません。
  • 抽象化レベル。サービスは、データの論理ビューと永続ビューの両方を処理するべきではありません。

そのような原則を破ると、次のような悪い状況につながる可能性があります。

  • コード パスをたどることができない (1 つの要求が 12 のサービスを理解するのが難しく、多くのレベルの条件付きロジックに依存する順序で行われる)。
  • どのコンポーネントが相互に依存しているかを知るのが難しい。
  • 強く結合されたコード (低レベルのサービスを変更すると、高レベルのサービスが変更されます)。

このような設計から得られる利点は非常に小さく (いくつかの@Autowired注釈を避けるだけです)、リスクを冒す価値はありません。

于 2013-08-20T12:56:21.043 に答える
1

  1. なぜ循環依存関係があるのでしょうか? 他のすべてのサービスを含む 1 つのサービスがあり、それを含む他のサービスはありません。そうは言っても、依存関係をコンストラクター引数ではなくプロパティとして設定することで、循環依存関係を簡単に解決できます。

  2. 私はそうは思いません。(エンドポイントなどで) ある種の階層を宣言するのは良いパターンですが、この方法の長所は何ですか? それなしでも、必要なすべてのサービスを自動配線できます。

于 2013-08-20T06:57:14.930 に答える
0

1)MasterService必ずしもループが含まれているとは限りません。その場合、問題が発生します。最初から Bean をループで構築しない方がはるかに簡単です。

2) 多くの短命の Bean に注入している場合、これが効果的である可能性がありますが、このアプローチには、MasterServiceインスタンスに干渉する人が他の Bean のサービスを台無しにする可能性があるという欠点があります。これを getter メソッドの背後に隠すことはできますが、通常、すべてをまとめてもあまりメリットはありません。

代わりに、通常は、関連するサービスをグループ化して (おそらくOtherService1とOtherService2)、インターフェイスに配置するのが最善です。これにより、テスト用のモックがはるかに簡単になり、関連する概念がまとめられます (理想的には、独自の jar/モジュール内で)。

于 2013-08-20T06:58:54.547 に答える
0

私は以前にそのようなパターンに出くわしたことがありません (1 つのサービスに他のサービスが含まれています)。私がよく見たり使ったりしているのは、以下のようなものです -

*SpecificController1 --> SpecificService1 --> SpecificDao1

SpecificController2 --> SpecificService2 --> SpecificDao2

ここで、SpecificService1がSpecificService2で既に利用可能な機能を必要とする場合にのみ、SpecificService2を参照します。

したがって、上記のパターンについていくつか質問があります。

  1. MasterService はどのように使用されますか? つまり、サービスを必要とするコントローラー (または誰か) は、最初に MasterService を使用して実際のサービスへの参照を取得するか、MasterService がデリゲートとして機能しますか?
  2. どのようなシナリオで、そのような設計が必要で、どのような利点がありますか?
于 2013-08-20T07:26:45.320 に答える