依赖注入和解决方案中的多个项目
我一直在关注 这篇文章涉及存储库模式和 UnitOfWork 与实体框架的使用。我还计划使用 Ninject 作为我即将进行的项目的 IOC 容器。
根据本文中的示例代码，NorthwindData 项目中的 NorthwindContext 类实现了 NorthwindModel 项目内部的 IUnitOfWork 接口。
如何利用依赖注入来消除 NorthwindModel 对 NorthwindData 的依赖？示例项目中的存储库类看起来好像它们依赖 IOC 容器来注入我理解的 NorthindContext 实例。
另外，我是否需要在解决方案中创建第三个项目来容纳 DI 内容。有关于如何设置的示例吗？
编辑：
我想我上面的问题源于一个更普遍的问题。
让这两个项目依赖于从 NWData 到 NWModel 的程序集引用是否不好？我的假设是 DI 将消除这种需求。
I have been following this article concerning the use of the repository pattern and UnitOfWork with entity framework. I am also planning to use Ninject as my IOC container for an upcoming project.
Given the sample code from the article, the NorthwindContext class in the NorthwindData project implements the IUnitOfWork interface which live inside of the NorthwindModel project.
How can I utilize dependency injection to eliminate the dependency on NorthwindModel to NorthwindData? The repository classes in the sample project look as if they would rely on an IOC container to inject instances of NorthindContext which I understand.
Also, Would I need to create third project in the solution to house the DI things. Any samples on how to set this up?
EDIT:
I suppose my question above stems from a more general question..
Is it bad to have the two projects dependent on an assembly reference from NWData to NWModel?? My assumption was that DI would elimnate this need.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
要打破 NorthwindModel 到 NorthwindData 的依赖关系，请查看存储库需要 NorthwindContext 提供的内容。将其拉入接口 IDataContext，在 NorthwindModel 项目中声明它并让 NorthwindContext 实现它。现在使用 DI 将 NorthwindContext 注入现在仅依赖于 IDataContext 的存储库。
关于可能的第三个项目：是的，有一个仅负责启动时设置的应用程序根项目可能是一个好主意。但这取决于范围。
To break the dependency from NorthwindModel to NorthwindData look at what the repositories need from the NorthwindContext. Pull that into an interface, IDataContext, declare that in the NorthwindModel project and let NorthwindContext implement it. Now use DI to inject NorthwindContext into the repositories that now only depend on IDataContext.
Regarding the possible third project: yes having an application root project responsible only setup at startup can be a good idea. But it depends on scope.