0

DIフレームワーク（私の場合はNinjectなど）を使用している大規模なプロジェクトでは、依存関係として使用できる他の「サービス」を見つけるために、新しい「サービス」を実装するときにどのようなオプションがありますか。DIを使用する前に、コードベースで、利用可能なすべての機能へのアクセスをほぼ提供する「神」オブジェクトへの参照を取得する傾向に気づきました。その後、Visual StudioのIntelliSenseは、利用可能なすべての機能を見つけるのに非常に役立ちます（明らかにこれそもそもそのようなオブジェクトを持っているというアーキテクチャ上の決定が不十分だったためにのみ、アプローチが可能でした）。

私はいくつかの可能な答えを得ることができ、他の人のために何がうまくいったのかに興味があります：

  1. 作業しているシステム全体を十分に理解して、他にどのようなクラス/サービスが存在するかを知る必要があります（たとえば、静的クラスがある場合、それらを使用できるようにするには、それらが存在することを知っている必要があります）。
  2. すべてのクラス/サービスがすべての開発者に理解されるように、コードベースの優れた外部ドキュメントを維持します（これにより、ドキュメントに大きな負担がかかります。私には思えます）。
  3. APIを作成して、DIコンテナー（Ninjectカーネル）にすべてのバインディングのリストを照会し、使用可能なサービス（おそらくシングルトンのみ）を確認します。これは、ビルドシステムの一部として実行して、開発者が参照できるビルドごとにドキュメントを自動的に生成することもできます。

これは他の開発者にとって問題になったことはありますか？

4

2 に答える 2

1

通常、すべてのサービスがシステムに存在することを確認してから、そのうちの1つを選択する必要はありません。機能にアクセスしたい。名前空間を使用してクラスを構造化し、どこで探すかが明確になるようにします。

たとえば、.NETで使用できるコレクションを知りたい場合は、入力System.Collections.Generic.すると、IntelliSenseからオプションのリストが表示されます。

于 2013-02-13T18:16:20.160 に答える
0

私は自分のコードベースを編成して、他のすべてのプロジェクトが参照できる中心的な「インターフェイス」プロジェクトを作成する傾向があります。次に、 myLoggerはインターフェイスを介してのみ利用可能ILoggerになり、ロギング モジュールは提供する具象ILoggerを選択できます。具体的なクラスを要求するべきではありません - これは DI の目的を無効にします。

一般に、新しいサービスを実装するときは、必要な依存関係をすでに知っている必要があります。何を使えばいいのかわからない場合は、知っている人に聞いてください。これは、適切なドキュメントを持つことと同じです。インテリセンスに頼ると、依存関係として何をすべきかについて非常に浅い考えが得られます。代わりに、ドキュメントを参照するか、その分野を理解している人に相談してください。

于 2013-02-14T11:11:16.577 に答える