依赖注入vs工厂模式
大多数引用了依赖注入的例子，我们也可以使用工厂模式来解决。 看起来，当涉及到使用/设计时，依赖注入与工厂之间的区别变得模糊或薄弱。
一旦有人告诉我，它如何使用它会产生变化！
我曾经使用过StructureMap的一个DI容器来解决问题，后来我重新设计了它来使用一个简单的工厂，并移除了对StructureMap的引用。
谁能告诉我他们之间有什么区别，以及在哪里使用什么，这里最好的做法是什么？
在使用工厂时，您的代码实际上仍然负责创建对象。 通过DI，您将该责任外包给另一个类或框架，这与您的代码是分开的。
我会建议保持概念简单明了。 依赖注入更多地是松散耦合软件组件的体系结构模式。 工厂模式只是将创建其他类的对象的责任分离到另一个实体的一种方式。 工厂模式可以被称为实施DI的工具。 依赖注入可以通过许多方式实现，如使用构造函数的DI，使用映射XML文件等。
依赖注入
汽车不要实例化零件本身，而是要求它需要运转的零件。
class Car
{
private Engine;
private SteeringWheel;
private Tires tires;
public Car(Engine engine, SteeringWheel wheel, Tires tires)
{
this.Engine = engine;
this.SteeringWheel = wheel;
this.Tires = tires;
}
}
厂
将这些部分放在一起以创建一个完整的对象，并隐藏调用者的具体类型。
static class CarFactory
{
public ICar BuildCar()
{
Engine engine = new Engine();
SteeringWheel steeringWheel = new SteeringWheel();
Tires tires = new Tires();
ICar car = new RaceCar(engine, steeringWheel, tires);
return car;
}
}
结果
正如你所看到的，工厂和DI是相辅相成的。
static void Main()
{
ICar car = CarFactory.BuildCar();
// use car
}
你还记得金发姑娘和三只熊吗？ 那么，依赖注入就是这样的。 这里有三种方法可以做同样的事情。
void RaceCar() // example #1
{
ICar car = CarFactory.BuildCar();
car.Race();
}
void RaceCar(ICarFactory carFactory) // example #2
{
ICar car = carFactory.BuildCar();
car.Race();
}
void RaceCar(ICar car) // example #3
{
car.Race();
}
例＃1 - 这是最糟糕的，因为它完全隐藏了依赖关系。 如果你将这种方法看作一个黑匣子，你就不会知道它需要一辆汽车。
示例＃2 - 这样会好一点，因为现在我们知道自从我们进入汽车工厂后我们需要一辆汽车。 但是这次我们传递得太多了，因为所有的方法实际上都需要一辆汽车。 当汽车可以在方法之外建造并通过时，我们正在通过一家工厂来建造汽车。
示例＃3 - 这是理想的，因为该方法确切地询问它需要什么。 没有太多或太少。 我不必为了创建MockCars而编写MockCarFactory，我可以直接通过模拟。它是直接的，接口不是谎言。
Misko Hevery的Google技术讲座令人惊叹，并且是我从我的例子中得出的基础。 http://www.youtube.com/watch?v=XcT4yYu_TTs
链接地址: http://www.djcxy.com/p/2179.html