Ioc 容器在企业应用程序中的放置
我最近一直在研究 Ioc 容器和 AOP，我对这些概念感到非常惊讶。然而，我正在努力决定如何以及在哪里实施容器。
以下文章建议在“应用程序入口点”中实现容器：
现在 - 我的思想实验应用程序将由多个 Visual Studio 项目组成（一个用于数据访问，winforms 应用程序）。假设我想使用 AOP 来通过 Log4net 进行日志记录，因此我在 Ioc 容器中设置了 log4net。 因此 WinForms 应用程序位于入口点，这就是 Ioc 容器应该去的地方。
问题是：如果我想在数据访问项目/层中记录内容，我应该添加一个 引用我的 winforms 应用程序，从那里获取 ioc 容器，从中获取 log4net 实例并使用它进行日志记录？
这意味着我的数据层依赖于 winforms 应用程序，这是不对的。我可以将容器作为解决方案中的“通用”项目吗？这样，所有相关项目（数据访问/winformsa 等）都可以访问该容器。 去这里的正确方法是什么？
I've been looking into Ioc containers and AOP recently, and I'm pretty amazed by the concepts. I'm struggling however to decide how and where to implement the container.
The articles below suggest implementing the container in the 'application entry point':
- Best Practices for IOC Container
- IOC across visual studio projects?
- Not understanding where to create IoC Containers in system architecture
Now - my thought-experiment application will consist of multiple visual studio projects ( one for data access, winforms application ). And let's say I want to use AOP for logging with Log4net, and so I setup log4net in the Ioc container.
So WinForms application in entry point, that's where Ioc container should go.
Here's the question: if I want to log stuff in my data access project/layer, should I add a
reference to my winforms application, get the ioc container from there, get the log4net instance out of it and use it for logging?
That would mean my data-layer depends on winforms application, that can't be right. How about I put the container is something like a 'Common' project within the solution. That way, all related projects (Data access/winformsa etc.) can access the container.
What is the right way to go here?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
您的应用程序的 Composition Root 将是 Windows 窗体项目。这是唯一应该引用 DI 容器的项目。
在所有其他项目中，应通过构造函数注入注入依赖项。所有像样的 DI 容器都理解这种模式，并使用它来自动连接来自组合根的依赖关系。
Your application's Composition Root would be the Windows Forms project. This is the only project which should have a reference to a DI Container.
In all other projects, dependencies should be injected via Constructor Injection. All decent DI Containers understand this pattern and use it to Auto-wire dependencies from the Composition Root.
我已将容器抽象为一个单独的程序集，所有其他程序集/项目都取决于其服务引用。容器项目只有一个类和（或多或少）一个方法：
容器构建要么发生在 MySpecialContainer 的构造函数中，要么只是添加另一个方法，如 Initialize() 等。
唯一的问题是，当我使用 Autofac 并且有一个 Windows 服务和 ASP.Net 项目都需要该容器时，这种方法对我来说失败了。每个服务都有其特定的范围生命周期服务要求：Windows 服务 - PerLifetimeScope，ASP.Net - PerHttpRequest。我想我可以将一个参数传递到 MySpecialContainer 中，该参数表示要配置的场景，但我决定直接采用 Autofac 依赖项。
好消息是，如果您坚持使用 ctor 注入，那么您可以非常轻松地替换各种容器实现 - Autofec、Ninject、StructureMap 等。
I've abstracted my container into a separate assembly that all other assemblies / projects depending on its services reference. The container project has just a single class and - more or less - a single method:
The container build would either occur in MySpecialContainer's ctor or just add another method like Initialize() or some such.
The only problem is this approach broke down for me when I used Autofac and had both a Windows Service and ASP.Net project needing the container. Each had its specific requirement for scoped-lifetime services: Windows Service - PerLifetimeScope, ASP.Net - PerHttpRequest. I guess I could've passed in an argument into MySpecialContainer that denoted which scenario to configure for but I decided just to take on an Autofac dependency directly.
The good news is, if you stick to ctor injection, then you can very easily swap out various container implementations - Autofec, Ninject, StructureMap, etc.