比诺，

我不认为你必须选择其中一个而不是另一个。

将依赖类或接口移动到类构造函数或setter的行为遵循DI模式。传递给构造函数或集合的对象可以用Factory实现。

什么时候使用?使用开发人员擅长的模式。他们觉得什么最舒服，什么最容易理解。

我相信DI是工厂的一种抽象层，但是它们还提供了抽象之外的好处。真正的工厂知道如何实例化单一类型并配置它。好的DI层通过配置提供实例化和配置多种类型的能力。

显然，对于具有一些简单类型的项目(在其构造中需要相对稳定的业务逻辑)，工厂模式易于理解、实现并且工作良好。

OTOH，如果您有一个包含许多类型的项目，您希望经常更改这些类型的实现，DI通过其配置为您提供了在运行时执行此操作的灵活性，而无需重新编译工厂。

IOC is a concept which is implemented by two ways. Dependency creation and dependency injection, Factory/Abstract factory are the example of dependency creation. Dependency injection is constructor, setter and interface. The core of IOC is to not depend upon the concrete classes, but define the abstract of methods(say an Interface/abstract class) and use that abstract to call method of concrete class. Like Factory pattern return the base class or interface. Similariliy dependency injection use base class/interface to set value for objects.

如果传递的参数可以在工厂中分组，那么它也是构造函数过度注入的一个很好的解决方案，看看下面的代码*):

public AddressModelFactory(IAddressAttributeService addressAttributeService,
        IAddressAttributeParser addressAttributeParser,
        ILocalizationService localizationService,
        IStateProvinceService stateProvinceService,
        IAddressAttributeFormatter addressAttributeFormatter)
    {
        this._addressAttributeService = addressAttributeService;
        this._addressAttributeParser = addressAttributeParser;
        this._localizationService = localizationService;
        this._stateProvinceService = stateProvinceService;
        this._addressAttributeFormatter = addressAttributeFormatter;
    }

看看构造函数，你只需要在那里传递IAddressModelFactory，所以参数更少*):

 public CustomerController(IAddressModelFactory addressModelFactory,
        ICustomerModelFactory customerModelFactory,
        IAuthenticationService authenticationService,
        DateTimeSettings dateTimeSettings,
        TaxSettings taxSettings,
        ILocalizationService localizationService,
        IWorkContext workContext,
        IStoreContext storeContext,
        ICustomerService customerService,
        ICustomerAttributeParser customerAttributeParser,
        ICustomerAttributeService customerAttributeService,
        IGenericAttributeService genericAttributeService,
        ICustomerRegistrationService customerRegistrationService,
        ITaxService taxService,
        CustomerSettings customerSettings,
        AddressSettings addressSettings,...

你可以看到在CustomerController中传递了很多参数，是的，你可以看到这是构造函数的过度注入，但这就是DI的工作方式。CustomerController没有任何问题。

*)代码来自nopCommerce。

工厂设计模式

工厂设计模式的特点是

一个接口 实现类 一个工厂

当你这样问自己时，你可以观察到一些事情

工厂什么时候为实现类创建对象——运行时还是编译时? 如果您想在运行时切换实现，该怎么办?-不可能

这些是由依赖注入处理的。

依赖注入

您可以使用不同的方式注入依赖项。为了简单起见，让我们使用接口注入

在DI中，容器创建所需的实例，并将它们“注入”到对象中。

这样就消除了静态实例化。

例子:

public class MyClass{

  MyInterface find= null;

  //Constructor- During the object instantiation

  public MyClass(MyInterface myInterface ) {

       find = myInterface ;
  }

  public void myMethod(){

       find.doSomething();

  }
}

我知道这个问题很老了，但我想补充一下我的观点，

我认为依赖注入(DI)在很多方面类似于可配置的工厂模式(FP)，从这个意义上说，你可以用DI做任何事情，你也可以用这样的工厂来做。

实际上，如果你使用spring为例，你可以选择自动装配资源(DI)或做这样的事情:

MyBean mb = ctx.getBean("myBean");

然后使用'mb'实例来做任何事情。这不是一个对工厂的调用，它将返回一个实例吗??

我注意到的大多数FP示例之间唯一真正的区别是，您可以在xml或其他类中配置“myBean”是什么，框架将作为工厂工作，但除此之外是一样的事情，您当然可以有一个工厂来读取配置文件或根据需要获得实现。

如果你问我的意见(我知道你没有)，我相信DI做了同样的事情，但只是增加了开发的复杂性，为什么?

嗯，首先，为了让您知道用于DI自动装配的任何bean的实现是什么，您必须进入配置本身。

但是…您不必知道正在使用的对象的实现，这种承诺又如何呢?啐!严重吗?当你使用这样的方法时……你不就是写实现的那个人吗??即使你没有，你不是几乎所有的时间都在看如何实现它应该做什么??

最后一点，不管DI框架向你承诺了多少，你将构建与它解耦的东西，不依赖于它们的类，如果你正在使用一个框架，你将围绕它构建一切，如果你不得不改变方法或框架，这将不是一个简单的任务……!…但是，由于您围绕特定的框架构建所有内容，而不是担心什么是最适合您的业务的解决方案，那么在这样做时，您将面临一个更大的问题。

事实上，我所能看到的FP或DI方法的唯一真正的业务应用是，如果你需要在运行时改变正在使用的实现，但至少我所知道的框架不允许你这样做，你必须在开发时让所有的配置都完美无缺，如果你需要使用另一种方法。

因此，如果我有一个类，它在同一个应用程序的两个作用域中执行不同的操作(比如说，同一个公司的两个控股公司)，我必须配置框架来创建两个不同的bean，并调整我的代码以使用每个bean。这是不是和我只是写这样的东西是一样的

MyBean mb = MyBeanForEntreprise1(); //In the classes of the first enterprise
MyBean mb = MyBeanForEntreprise2(); //In the classes of the second enterprise

和这个一样:

@Autowired MyBean mbForEnterprise1; //In the classes of the first enterprise
@Autowired MyBean mbForEnterprise2; //In the classes of the second enterprise

这:

MyBean mb = (MyBean)MyFactory.get("myBeanForEntreprise1"); //In the classes of the first enterprise
MyBean mb = (MyBean)MyFactory.get("myBeanForEntreprise2"); //In the classes of the second enterprise

在任何情况下，您都必须更改应用程序中的某些内容，无论是类还是配置文件，但您必须重新部署它。

这样做不是很好吗?

MyBean mb = (MyBean)MyFactory.get("mb"); 

通过这种方式，您可以设置工厂的代码以在运行时获得正确的实现，这取决于登录的用户企业??这很有帮助。您只需添加一个带有新类的新jar，并在运行时设置规则(或者如果您保留此选项，则添加一个新的配置文件)，无需更改现有类。这将是一个动态工厂!

这不是比为每个企业编写两个配置，甚至为每个企业编写两个不同的应用程序更有帮助吗?

You can tell me, I don't need to do the switch at runtime ever, so I configure the app, and if I inherit the class or use another implementation I just change the config and redeploy. Ok, that can also be done with a factory. And be honest, how many times do you do this? maybe only when you have an app that's going to be used somewhere else in your company, and you are going to pass the code to another team, and they will do things like this. But hey, that can also be done with the factory, and would be even better with a dynamic factory!!

不管怎样，评论区是开放的，你可以杀了我。