2

アプリケーションの一部のソフトウェア コンポーネントでは、起動とシャットダウンのアクティビティが必要です。

質問 1: Scala でそのような「サービス」を開始および停止するためのベスト プラクティスは何ですか?

私は自分のアプリケーションで依存性注入 (DI) を使用しています。私の現在の理解では、DIはソフトウェア コンポーネント間の依存関係を宣言しますが、副作用がないはずです(つまり、DI メカニズムはそれ自体でサービスを開始/停止するべきではありません)。したがって、DI はサービスのアクティブ化と直交しています。

ただし、重複があるようです。アプリケーションに が含まれておりNotificationService、それが を使用しているとしSchedulingServiceます。そこで、スケジューリング サービスの実装を通知サービスの実装に挿入し、これらのサービスを手動で開始および停止します。ただし、DI フレームワークには、どのサービスをインスタンス化する必要があるか (したがって開始/停止する必要があるか)、どのサービスがどのサービスに依存しているか (したがって、サービスを開始/停止する必要がある順序) を知るためのすべての情報が手元にあります。したがって、それらを開始/停止する方法を提供でき、ボイラープレートコードを節約できます!

質問 2: DI (Guice など) を拡張して、注入されたサービスを記録し、それらを開始/停止する方法を提供する試みはありますか?

4

1 に答える 1

1

質問 1 では、依存性注入戦略は Java で十分に確立されており、これらは通常、直接 Scala に変換できます。ただし、Scala の方がうまくいくと思います。そのプライマリ コンストラクターはコンストラクター ベースの依存性注入に非常に適しており、多くの場合、さまざまなアプローチ (セッター注入、注釈ベースの注入など) の中で最も雑然としていないように感じられます。

最近のプロジェクトでは、もともと Spring を使用していましたが、less is moreポリシーに変更し、Spring を完全に削除しました。

  • 私たちは Scala をテスト主導の DI オブジェクト指向の方法で使用し、XML はほとんど使用しませんでした (web.xmlもちろん、残りの 1 つは Web アプリケーションに必要でした)。
  • 単一のBootstrapクラスは、必要な依存性注入を使用して、すべてのリソースとサービスを正しい順序で構成しました。
  • Bootstrapもちろん から始まりましたweb.xml。
  • 代わりに統合テストによってテストされたを除いて、すべてが単体テストされました。Bootstrap

コンポーネントのスイートが与えられた場合、いくつかの代替構成を配線するには、単に異なるBootstraps. これを純粋に Scala で行うと、コードの透過性と IDE 内でのリファクタリングのサポートという大きなメリットがもたらされ、比較的労力がかかりません。

質問 2 については、明確な答えがありません。しかし、Less is moreアプローチをお勧めします。フレームワークが必要ないだけなら、問題はそれほど重要ではないかもしれません。

于 2013-03-23T14:26:01.253 に答える