在构造函数中注入多个服务 VS 在构造函数中注入单个 ServiceFactory
Inject multiple services in constructor VS inject a single ServiceFactory in constructor
我想知道这两种解决方案之间的最佳方法是什么:
使用unity我注册了N个服务interfaces/classes
internal class Configurator
{
private static IUnityContainer container = new UnityContainer();
internal static void Configure()
{
container.RegisterType<ICustomerService, CustomerService>();
container.RegisterType<IPhoneService, PhoneService>();
container.RegisterType<IUserService, UserService>();
...
}
internal static T Resolve<T>()
{
return container.Resolve<T>();
}
}
其中所有接口都实现了 IService
public interface ICustomerService : IService
public interface IPhoneService: IService
public interface IUserService: IService
我还创建了一个 ServiceFactory class
public class ServiceFactory : IServiceFactory
{
public T GetService<T>() where T : IService
{
return Configurator.Resolve<T>();
}
}
现在我的疑问是:
解决方案 1:
public class TestViewModel
{
private ICustomerService _customerService;
private IPhoneService _phoneService;
private IUserService _userService;
public TestViewModel(ICustomerService customerService, IPhoneService phoneService, IUserService userService)
{
_customerService = customerService;
_phoneService = phoneService;
_userService = userService;
}
解决方案 2:
public class TestViewModel
{
private IServiceFactory _serviceFactory;
private IUserService _userService;
public IUserService UserService
{
get
{
if(_userService == null)
_userService = _serviceFactory.GetService<IUserService>();
return _userService;
}
}
public MainWindowViewModel(IServiceFactory serviceFactory)
{
_serviceFactory = serviceFactory;
}
我个人更喜欢解决方案 2,因为
1) 如果我必须在单个构造函数中注入大量服务,我可以只注入工厂
2) 服务仅在请求时初始化(在解决方案 1 中,如果用户永远不会 call/use 所有这些,它们也会在构造函数中初始化)
您是否同意解决方案 2 更好?是否有任何禁忌症?我想听听您的一些意见...
ServiceFactory
class 基本上充当 Service Locator 被认为是反模式。原因是这样你的服务比它需要的更强大。通过在构造函数中声明您的依赖项,您可以严格指导您在 class 中需要和使用的内容。
如果你有太多的构造函数参数,它可能是一种代码味道,表明你的 class 可能比它应该做的更多,并且可能违反了 Single Responsibility Principle。在这种情况下,您应该考虑将 class 重构为更小的子 class,每个子执行更小的任务。
我对这个问题的看法是第一个解决方案更好
我想知道这两种解决方案之间的最佳方法是什么:
使用unity我注册了N个服务interfaces/classes
internal class Configurator
{
private static IUnityContainer container = new UnityContainer();
internal static void Configure()
{
container.RegisterType<ICustomerService, CustomerService>();
container.RegisterType<IPhoneService, PhoneService>();
container.RegisterType<IUserService, UserService>();
...
}
internal static T Resolve<T>()
{
return container.Resolve<T>();
}
}
其中所有接口都实现了 IService
public interface ICustomerService : IService
public interface IPhoneService: IService
public interface IUserService: IService
我还创建了一个 ServiceFactory class
public class ServiceFactory : IServiceFactory
{
public T GetService<T>() where T : IService
{
return Configurator.Resolve<T>();
}
}
现在我的疑问是:
解决方案 1:
public class TestViewModel
{
private ICustomerService _customerService;
private IPhoneService _phoneService;
private IUserService _userService;
public TestViewModel(ICustomerService customerService, IPhoneService phoneService, IUserService userService)
{
_customerService = customerService;
_phoneService = phoneService;
_userService = userService;
}
解决方案 2:
public class TestViewModel
{
private IServiceFactory _serviceFactory;
private IUserService _userService;
public IUserService UserService
{
get
{
if(_userService == null)
_userService = _serviceFactory.GetService<IUserService>();
return _userService;
}
}
public MainWindowViewModel(IServiceFactory serviceFactory)
{
_serviceFactory = serviceFactory;
}
我个人更喜欢解决方案 2,因为
1) 如果我必须在单个构造函数中注入大量服务,我可以只注入工厂
2) 服务仅在请求时初始化(在解决方案 1 中,如果用户永远不会 call/use 所有这些,它们也会在构造函数中初始化)
您是否同意解决方案 2 更好?是否有任何禁忌症?我想听听您的一些意见...
ServiceFactory
class 基本上充当 Service Locator 被认为是反模式。原因是这样你的服务比它需要的更强大。通过在构造函数中声明您的依赖项,您可以严格指导您在 class 中需要和使用的内容。
如果你有太多的构造函数参数,它可能是一种代码味道,表明你的 class 可能比它应该做的更多,并且可能违反了 Single Responsibility Principle。在这种情况下,您应该考虑将 class 重构为更小的子 class,每个子执行更小的任务。
我对这个问题的看法是第一个解决方案更好