1

私のシステムで発生し続ける状況があり、適切なコード/構成パターンを探しています。私はまだ私を幸せにするものを思い付いていません。

システムはスプリングベースで、ほぼすべての Bean が遅延初期化されます。同じスプリング コンテキストを使用するさまざまなメイン クラスが多数あります。それぞれが、いくつかの Bean を明示的に初期化することによって Bean の異なるサブセットを使用することになり、Spring がすべての依存関係を初期化します。この1つのケースを除いて、すべてがうまく機能します。

問題は、一部の Bean が (Spring 構成で) ビジネス Bean が宣言されているパターンを使用し、別の Bean がそれに依存していくつかの周辺機能を提供することです。ただし、他の Bean の自然な依存関係は前者であり、ビジネス クラスです。

次に例を示します。

<bean id="cache">
  ...
</bean>

<bean id="cacheCuller" class="ScheduledJobBean">
  <property name="scheduler" ref="scheduler"/>
  <property name="jobDetail">
    <bean class="org.springframework.scheduling.quartz.MethodInvokingJobDetailFactoryBean">
      <property name="targetObject" ref="cache"/>
      <property name="targetMethod" value="removeExpiredEntries"/>
      <property name="concurrent" value="false"/>
    </bean>
  </property>
  <property name="repeatInterval" value="300000" />
</bean>

したがって、上記の 2 番目の Bean は基本的に、最初の Bean のメソッドを定期的に呼び出すトリガーをスケジューラに登録します。これらの Bean はすべて遅延であることを忘れないでください。アクティブな「キャッシュ」クライアント Bean がない場合、「cacheCuller」を作成して「キャッシュ」を初期化する必要はありません。依存関係に注入する必要があるときに「キャッシュ」を初期化する必要がありますが（これは簡単です）、その後すぐに「cacheCuller」を初期化することも必要です（これは難しいです）。

スケジューリングロジックを「キャッシュ」クラスに入れることができることは知っていますが、Spring 構成のままにしておくとよいと思いました。また、「キャッシュ」クラスをスプリング固有のコードから解放したいと思います。他の Bean が自然に「cacheCuller」に依存している場合、これは簡単ですが、そうではありません。

Bean を MBeanServer に登録するなど、他の領域でも同じ状況が発生します。2 番目の Bean でビジネス Bean を登録したいのですが、他の (3 番目の) Bean の依存関係として使用されていない場合は、ビジネス Bean 自体を初期化したくありません。

4

2 に答える 2

6

depends-onを探していると思います。

于 2011-07-18T17:55:26.150 に答える
0

同じスプリング コンテキストを使用するさまざまなメイン クラスが多数あります。それぞれが、いくつかの Bean を明示的に初期化することによって Bean の異なるサブセットを使用することになり、Spring がすべての依存関係を初期化します。

たぶん、このアプローチを再検討する必要があります。

アプリケーション コンテキストを複数のファイルに分割し、各メイン クラスにそれらの必要な組み合わせをロードさせることができます。これにより、アプリケーションのコンテキストがよりモジュール化され、IMHOを理解しやすくなります（たとえば、説明した問題を解消します）。

于 2011-08-04T10:36:39.683 に答える