UnityContainer的使用和最佳实践
在应用程序中使用 UnityContainer 来访问对应用程序不同部分（但同一程序集）的对象的引用是否错误？
应用程序 (WPF) 有几个需要相互访问的区域，我使用 UnityContainer 来做到这一点。例如，“主”区域（即绘图区域）后面有一个演示者，它管理其所有业务逻辑，并且我已在容器中以及我需要的应用程序的其他部分中注册了该演示者的实例要访问它，我要控制该区域，我通过 UnityContainer 访问它。
不确定这是一种好的做法还是坏的做法。
Is it wrong to use UnityContainer in an app to access references to objects from different parts of the application (but the same assembly)?
The application (WPF) has several regions that need to access each other and I have used UnityContainer to do that. For example, the "main" region (which is a drawing area) has a presenter behind it, that manages all it's business logic, and I have registered this instance of presenter in the container, and in other parts of the application where i need to access it i to control that region, i access it via UnityContainer.
Not sure if that's a good practice or a bad one.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
不，事实上，这就是它的目的。有一个名为 ServiceLocator 的库，它工作得很好，可以让你切换 IoC 容器，提供一种查找容器的方法，等等。我发现它太过分了，因为我从来没有必要切换容器......获取容器的静态“工厂”通常就足够了。通常，只有顶级类必须调用它，并且它负责组装所有依赖项。
No, in fact, that's kind of what its purpose it. There is a library out there called ServiceLocator that works good that allows you to switch out IoC containers, provides a way to lookup the container, etc. I find it overkill in that I've never had to swap out containers... Using a static "factory" to get the container is usually good enough. Usually, only the top level class has to call it and it is responsible for assembling all the dependencies.