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");
}

你可以看到我创建了一个上下文，然后我创建了我的存储库并为它们提供了现有的上下文，最后我创建了我的服务并为它们提供了存储库。然后，我可以自由使用这些服务。

不过，该代码非常冗长。我可以通过在服务内部而不是外部创建存储库实例来使其更清晰。

不过，我在尝试这样做时感到困惑。我将 Ninject 用于我的 DI，并且我想创建一个绑定到构造函数IAccountRepository内部接口的类的实例。IAccountService最重要的是，它还需要知道如何使用提供IPortalContext的。

我是否必须将 Ninject 作为依赖项添加到我的服务层项目并在其中创建一个新内核并在内部使用 Kernel.Get() 作为IAccountService构造函数？或者有没有办法告诉 Ninject 从我的单元测试中完成这一切，例如？

4

1 回答 1

2

我想创建一个绑定到构造函数IAccountRepository内部接口的类的实例IAccountService

那你为什么要使用 NInject？该依赖项应该被注入（因此得名），而不是在服务中创建。

在服务内部执行此操作可能看起来“更干净”，但是您失去了松散耦合层的所有好处。

如果您发现您正在重复这 6 行代码（这不是“冗长”恕我直言），那么您可以将其重构为一个单独的函数（在您的单元测试和应用程序层中）并在需要时调用它。

于 2013-10-16T18:54:34.300 回答