服务定位器模式和 DDD
我有一个带有 DDD 数据层的框架，它使用服务定位器模式。但是，目前我使用全局静态 ServiceLocator 类来存储所有引用。我想将其重构为正确的实现，其中类实现 IServiceProvider 接口，并删除全局静态 ServiceLocator 类。
现在，除了实体类之外，几乎所有地方都可以使用 IServiceProvider 接口扩展现有类。问题是，我认为实体类必须实现 IServiceProvider 非常奇怪，但我确实需要一种访问服务提供者的方法，以便能够通过我的 IoC 容器解析存储库。
无需在我的实体上实现 IServiceProvider 即可实现服务定位器模式的最佳方法是什么？
I have a framework with a DDD data layer which uses the service locator pattern. However, currently I use a global static ServiceLocator class which stores all the references. I would like to refactor this into a correct implementation where classes implement the IServiceProvider interface and where I remove the global static ServiceLocator class.
Now, almost everywhere it isn't issue to extend existing classes with the IServiceProvider interface, except for the entity classes. The problem is that I would think it very strange for the entity classes to have to implement IServiceProvider, but I do need a way to access a service provider to be able to resolve repositories through my IoC container.
What would be the best way to implement the service locator pattern without having to implement IServiceProvider on my entities?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
为什么实体（业务对象）要公开 IServiceProvider？它是一个业务对象，而不是服务。而IServiceProvider甚至不是针对服务的，它是一种暴露服务提供者的IOC机制。
如果有的话，您的 ORM / 业务对象框架 / 运行时是一个服务提供者，但不是单个实体。
让我返回这个问题：我没有看到任何实体公开 IServiceProvider 的合理编程概念。
---更新
服务仅应提供服务定位器 - 并且您应该拥有一个。对于定义的线程访问元素（例如名称：UI - UI 元素必须由 UI 线程的规范访问）的情况，您可以使用线程静态变量，这会破坏全局单例。
Why the heck would an entity (business object) expose IServiceProvider? It is a business object, not a service. And IServiceProvider is not even for services, it is an IOC mechanism to expose service providers.
if anything, your ORM / business object framework / runtime is a service provider, but not the individual entities.
let me return the question: I dont see any sensible programming concept where entities expose IServiceProvider to start with.
---update
Services only should provide a service locator - and you should have one. You can use thread static variables for those cases where defined threads access elements (name: UI for example - UI elements must be accessed by spec by the UI thread) which breaks the global singleton.
服务定位器最好与控制反转容器（例如 Unity、Castle Windsor 或 NInject）结合使用。请参阅 http://commonservicelocator.codeplex.com/wikipage？ title=Unity%20Adapter&referringTitle=Home&ProjectName=commonservicelocator 查看适用于的服务定位器示例团结。
请记住，服务定位器可以被视为一种反模式——应该非常小心地使用它。最好使用构造函数或属性注入来代替。但在依赖关系非常依赖于正在执行的功能的情况下，服务定位器有一席之地。
A Service Locator is best used in combination with an Inversion of Control container such as Unity, Castle Windsor or NInject. See http://commonservicelocator.codeplex.com/wikipage?title=Unity%20Adapter&referringTitle=Home&ProjectName=commonservicelocator for an example of a service locator that works with Unity.
And remember that Service Locator can be seen as an antipattern -- it should be used very carefully. It is much better to use constructor or property injection instead. But in cases where the dependencies are very much dependent on the functionality being executed, Service Locator has a place.