私はNinjectと協力して、依存性注入を使用してアプリケーションを実装しています。私は概念をかなり完全に理解しており、アプリケーションがDIを使用して実現した疎結合でテスト可能なアーキテクチャを本当に気に入っているように感じます。しかし、私は特定の種類のサービスに苦労しており、自分が何か間違ったことをしているのか、他の人が同じことをしているのかについての洞察を探しています。
基本的に、私はそれらに依存する他のサービスを持たないいくつかのサービス/クラス(かなり少数)になってしまいます。このため、クラスはアプリケーションで有用な役割を果たすため、必要な場合でもインスタンス化されることはありません。例として、私がIMonkeyRepository
サービスとサービスを持っているとしましょうIMonkeyPopulator
。IMonkeyPopulator
サービスには実際にはパブリックAPIがなく、その唯一の責任(単一責任の原則に従う)は、ネットワーク上でサルを発見し、それらを投入することであると想定IMonkeyRepository
します。このサービスはIMonkeyRepository
、ネットワークとの相互作用を処理するために、およびおそらく他のいくつかのサービスに依存しています(たとえば、ポートとアドレスの構成データ)。ただし、にIMonkeyPopulator
はパブリックAPIはなく、単なる空のインターフェースです。
これは悪いデザインですか、それとも私が見逃しているある種のコードの臭いですか?この機能をリポジトリ自体に移動することはできますが、それはSRPに違反しているように見えます(リポジトリには便利なアクセス機能などがあり、実際には複数のサービスが存在する可能性があります)。私が検討または試したが満足していないいくつかのアプローチは次のとおりです。
- サービスに、サービスを開始するために呼び出す必要のあるStartなどの単一のパブリックメソッドを持たせます。これには、この呼び出しを行うためにシステム内のいくらか任意の場所を決定する必要があるという欠点があります。
- Ninjectカーネルの作成時にインスタンス化する定数にサービスをバインドします。これには、誰もこのサービスに依存していないことを理解する必要があるため、特別に処理する必要がありますが、これは間違っているようです。
- いくつかのメンバーをサービスに追加し、これらの値(サービスのステータスなど)を読み取るGUIをアプリケーションのどこかに作成します。明らかに、この理由でのみ存在するGUIをアプリケーションに追加する必要があるのは非常にばかげています(ただし、デバッグなどに役立つ場合もあります)。
何か考えやガイダンスはありますか?