Question

注入工厂是不错的做法，然后在构造函数中执行许多对象的实例化？

private readonly SafeClient<AccountProxy, IAccountService> _accountProxy;
private readonly SafeClient<AccountClassProxy, IAccountClassService> _accountClassProxy;
private readonly SafeClient<CarrierProxy, ICarrierService> _carrierProxy;
private readonly SafeClient<TransportationTypeProxy, ITransportationTypeService> _transportationTypeProxy;

public AccountController(ISafeClientFactory clientFactory)
{
    clientFactory.UserName = "user";
    clientFactory.Password = "password";
    _accountProxy = clientFactory.CreateClient<AccountProxy, IAccountService>();
    _accountClassProxy = clientFactory.CreateClient<AccountClassProxy, IAccountClassService>();
    _carrierProxy = clientFactory.CreateClient<CarrierProxy, ICarrierService>();
    _transportationTypeProxy = clientFactory.CreateClient<TransportationTypeProxy, ITransportationTypeService>();
}

或者只是注入一切更好吗？优缺点都有什么？对不起，我对这整个DI事情都很陌生。感谢。

public AccountController(
    ISafeClient<IAccountService> accountProxy,
    ISafeClient<IAccountClassService> accountClassService,
    ISafeClient<ICarrierService> carrierService,
    ISafeClient<ITransportationTypeService> transportService) 
{
     //assignment here
}

Answer 1

我通常会选择第二个例子，这就是我的理由：

如果A 的依赖关系B 可以在构造时为A实例化，那么应该在A之外实例化，构造函数注入A中。如果还不够在施工时为A实例化B的信息，然后注入一个可以在存在足够信息时实例化B的工厂。

Answer 2

通过向构造函数中注入工厂，您隐藏了真正的依赖项，并且与Service Locator anti-pattern具有相同的缺点。这些缺点包括：

它隐藏了一个类的依赖项，导致运行时错误而不是编译时错误
它使代码更难以维护，因为不清楚何时引入重大变更
使组件的使用者更难以查看组件是否具有Captive Dependency并且使工具失明;他们无法发现这些错误。
可能会隐藏一个类使用太多依赖项的事实。换句话说，它隐藏了这个类可能违反单一责任原则的事实。

您通常会使用工厂来延迟构建对象图形的一部分，但是如果您在构造函数中调用工厂，则根本不会延迟构造。你没有额外的好处，只有缺点。

因此，直接注入依赖项绝对更好。

注入工厂，让它执行创建，或注入一切？

2 个答案: