UnityContainer.Resolve 还是 ServiceLocator.GetInstance？
这似乎是一个愚蠢的问题，因为在我的代码中一切正常，但我已经用我的 Unity 容器 _ambientContainer 注册了一个单例：
_ambientContainer.RegisterType<Application.StateContext>(new ContainerControlledLifetimeManager());
为了避免使用我的本地字段，我使用
get {
return ServiceLocator.Current.GetInstance<Application.StateContext>();
}
：我的 get 属性来获取我的对象的实例。 这样我总是得到相同的实例（Application.StateContext 仍然是单例），还是 GetInstance 创建一个新实例？
使用本地 _ambientContainer 字段是否更好？
get {
return _ambientContainer.Resolve<Application.StateContext>();
}
谢谢。
It could seem a stupid question because in my code everything is working, but I've registered a singleton this way with my Unity container _ambientContainer:
_ambientContainer.RegisterType<Application.StateContext>(new ContainerControlledLifetimeManager());
In order to avoid to use my local field, I use:
get {
return ServiceLocator.Current.GetInstance<Application.StateContext>();
}
inside my get property to get an instance of my object.
This way I get always the same instance (Application.StateContext is still a singleton) or does GetInstance create a new one?
Is it better to use the local _ambientContainer field instead?
get {
return _ambientContainer.Resolve<Application.StateContext>();
}
Thank you.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
将容器的实例传递给使用者类通常不是一个好主意，因为您不再保证应用程序中只有一个地方可以注册组件和服务（称为 a href="http://blog.ploeh.dk/2011/07/28/CompositionRoot.aspx" rel="noreferrer">组合根）。
类应该在其公共 API 中声明它们的依赖关系，最好通过将它们指定为构造函数参数，容器将自动提供一个实例每当它被要求解析特定类型时（称为自动装配的过程）。
依赖注入通常是首选，但并不总是适用。在这些情况下，使用 服务定位器（就像您在示例中所做的那样）是将类与其分离的下一个最佳解决方案依赖项。
总之，如果依赖注入不是一个选项，我将避免让我的类直接引用容器，而是让它们通过服务定位器访问它。
Passing around instances of the container to consumer classes isn't generally a good idea, since you are no longer guaranteed to have a single place in your application where components and services are being registered (known as the Composition Root).
Classes should state their dependencies in their public API, ideally by specifying them as constructor arguments, which the container will automatically provide an instance for whenever it's been asked to resolve a specific type (a process known as Autowiring).
Dependency Injection is usually the preferred choice but it isn't always applicable. In those cases using a Service Locator, like you're doing in your example, is the next best solution to decouple a class from its dependencies.
In conclusion, if Dependency Injection is not an option, I would avoid having my classes reference the container directly and instead have them access it through a Service Locator.
最好避免这两种使用容器的方式。
ServiceLocator 被认为是现代应用程序体系结构中的反模式。
Preferably you should avoid both ways of (ab)using your container.
The ServiceLocator is considered an anti-pattern in modern application architecture.
我假设
ServiceLocator类型来自 CommonServiceLocator 项目，并且您正在使用 Unity 适配器，在这种情况下，GetInstance会调用container.Resolve，因此这两行是等效的。您可以在此处查看源代码 - http://commonservicelocator.codeplex.com /wikipage?title=Unity%20Adapter&referringTitle=Home
I'm assuming that the
ServiceLocatortype is from the CommonServiceLocator project, and that you're using the Unity adapter, in which caseGetInstanceinvokescontainer.Resolve, so both lines are equivalent.You can view the source here - http://commonservicelocator.codeplex.com/wikipage?title=Unity%20Adapter&referringTitle=Home