我正在开发一个具有多层架构的项目。这些层在他们自己的类库项目中,但都在同一个解决方案中。在较低层,我有我的模型,存储库和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从我的单元测试中做到这一点,例如?
答案 0 :(得分:2)
我想创建绑定到
IAccountRepository
构造函数内的IAccountService
接口的类的实例
那你为什么要使用NInject?该依赖项应该注入(因此名称),而不是在服务中创建。
在服务中执行此操作可能看起来“更干净”,但是您将失去松散耦合图层的所有好处。
如果您发现重复这6行代码(不是“详细”恕我直言),那么您可以将其重构为一个单独的函数(在您的单元测试和您的应用层中),并在需要时调用它