1

複数のアーキテクチャ層を持つプロジェクトに取り組んでいます。これらのレイヤーは独自のクラス ライブラリ プロジェクトにありますが、すべて同じソリューションにあります。下位層では、モデル、リポジトリ、および dbcontext を使用して、リポジトリ パターンを実行しています。リポジトリの上には、すべてのビジネス ロジックを含むサービス レイヤーがあります。現在、これらのさまざまなコンポーネントをインスタンス化して使用するためのコードは、単体テストでは次のようになります。

using (var context = m_kernel.Get<IPortalContext>())
{
    var accountRepository = m_kernel.Get<IAccountRepository>(new ConstructorArgument("context", context));
    var eventRepository = m_kernel.Get<IEventRepository>(new ConstructorArgument("context", context));

    var accounts = m_kernel.Get<IAccountService>(new ConstructorArgument("repository", accountRepository));
    var events = m_kernel.Get<IEventService>(new ConstructorArgument("repository", eventRepository));

    var account = accounts.GetByUsername("test@test.com");
}

コンテキストを作成し、リポジトリを作成して既存のコンテキストを提供し、最後にサービスを作成してリポジトリを提供することがわかります。その後、私は自由にサービスを利用できます。

ただし、そのコードは非常に冗長です。外部ではなく、サービスの内部にリポジトリ インスタンスを作成することで、よりクリーンにすることができます。

ただし、これをやろうとしているときに混乱が生じます。DI に Ninject を使用しており、コンストラクターIAccountRepository内のインターフェイスにバインドされたクラスのインスタンスを作成したいと考えています。IAccountServiceその上、提供された も使用することを知る必要がIPortalContextあります。

Ninject を依存関係としてサービス レイヤー プロジェクトに追加し、そこに新しいカーネルを作成し、IAccountServiceコンストラクターの内部で Kernel.Get() を使用する必要がありますか? または、たとえば、単体テストからこれをすべて実行するように Ninject に指示する方法はありますか?

4

1 に答える 1

2

コンストラクターIAccountRepository内のインターフェイスにバインドされたクラスのインスタンスを作成したいIAccountService

では、なぜ NInject を使用しているのですか? その依存関係は、サービス内で作成するのではなく、注入する必要があります (名前の由来)。

サービス内でこれを行う方が「クリーン」に見えるかもしれませんが、レイヤーを疎結合する利点がすべて失われます。

これらの 6 行のコードを繰り返していることがわかった場合 (これは「冗長な」IMHO ではありません)、それを別の関数 (単体テストとアプリ レイヤーで) にリファクタリングし、必要なときにいつでも呼び出すことができます。

于 2013-10-16T18:54:34.300 に答える