12

NInject のモジュール アーキテクチャは便利そうに見えますが、少し混乱するのではないかと心配です。

モジュールをどのように編成しますか? それらをどのアセンブリに保持し、どの配線をどのモジュールに入れるかをどのように決定しますか?

4

2 に答える 2

7

各サブシステムはモジュールを取得します。もちろん、「サブシステム」としての分類を正当化するものの定義は依存します...

場合によっては、下位レベルのサブシステム/コンポーネントが最終的な正式な決定を行う立場にないため、一部のバインディングの責任が上位レベルに押し上げられます。場合によっては、パラメーターをモジュールに渡すことでこれを達成できます。

于 2009-11-09T08:52:01.280 に答える
2

NInjectを数年間使用した後、自分の投稿に返信します。

例として書店を使用して、NInjectModulesを整理する方法は次のとおりです。

  • BookStoreSolution
    • Domain.csproj
    • Services.csproj
      • CustomerServicesInjectionModule.cs
      • PaymentProcessingInjectionModule.cs
    • DataAccess.csproj
      • CustomerDatabaseInjectionModule.cs
      • BookDatabaseInjectionModule.cs
    • CustomSecurityFramework.csproj
      • CustomSecurityFrameworkInjectionModule.cs
    • PublicWebsite.csproj
      • PublicWebsiteInjectionModule.cs
    • Intranet.csproj
      • IntranetInjectionModule.cs

つまり、システム内の各プロジェクトには、そのプロジェクトのクラスのバインディングを設定する方法を知っている1つ以上のNInjectモジュールがあらかじめパッケージ化されています。

ほとんどの場合、個々のアプリケーションは、プロジェクトによって提供されるデフォルトのインジェクションモジュールに大幅な変更を加えたくないでしょう。たとえば、DataAccessプロジェクトをインポートする必要がある小さなWinFormアプリを作成している場合、通常は、プロジェクトのすべてのRepository<>クラスを関連するIRepository<>インターフェイスにバインドする必要があります。

同時に、個々のアプリケーションに特定のインジェクションモジュールの使用を強制するものは何もありません。アプリケーションは、独自のインジェクションモジュールを作成し、インポートしているプロジェクトによって提供されるデフォルトのモジュールを無視できます。このようにして、システムは依然として柔軟で分離されたままです。

于 2011-09-23T01:53:10.337 に答える