我在几个使用Unity的asp.net mvc3教程中看到了这行代码。我认为服务定位器是一种反模式,不是最佳实践。这个服务定位器与定义的反模式不同吗?还是这行代码/实现被认为是不好的做法。
ServiceLocator.SetLocatorProvider(() => new UnityServiceLocator(Container));
我在几个使用Unity的asp.net mvc3教程中看到了这行代码。我认为服务定位器是一种反模式,不是最佳实践。这个服务定位器与定义的反模式不同吗?还是这行代码/实现被认为是不好的做法。
ServiceLocator.SetLocatorProvider(() => new UnityServiceLocator(Container));
虽然这个问题比较老,但是为了让其他人受益:
虽然我绝对同意 "服务定位器是一种反模式" 的口号,但也有例外。
当你使用依赖注入(如Unity)时,确实不要使用ServiceLocator,而是只对所有服务类使用构造函数注入。(还不要对值对象(如DTO)使用“new”)
但是,在某些情况下,你简单地无法使用构造函数注入,而唯一的获取某个服务的方法是使用特殊处理来直接访问Unity容器,在这种情况下,ServiceLocator是实现这一目标的良好标准方式。例如,当该类不是由你(或更具体地说,不是由Unity)实例化,而是由.NET框架实例化时。
一些ServiceLocator可能有用的简单示例包括从以下位置获取已注册在您的Unity容器中的服务:
请注意,这行代码并非理想:
ServiceLocator.SetLocatorProvider(() => new UnityServiceLocator(Container));
每次访问ServiceLocator.Current属性时,都会执行提供的委托,也就是说,每次都会创建一个新的UnityServiceLocator对象。相反,你可能想要这样实现:
IServiceLocator locator = new UnityServiceLocator(container);
ServiceLocator.SetLocatorProvider(() => locator);