依赖注入

Question

在 .net 程序开发中，你应该广泛地使用自定义的事件，驱动你的程序的通知流程。进行明确的设计。不要使用侵入性、破坏程序可调试、可维护性的，成事不足百事有余的依赖注入方式。

Answer 1

public class ProductController : Controller
    {
        private readonly IProductService _productService;
        public ProductController(IProductService productService)
        {
            _productService = productService;//这里你看起来是不是很怪，接口赋值给接口，没有说谁是真正的实现者
        }那么运行的时候到底谁是真正的实现者，由IOC来决定，
你这里看不到就是 分离了
按OOP的很多思考原则来说，就好就是你不认识我 我不认识你，那么就是解耦
当然 做人最好不好解耦 呵呵

Answer 2

IOC就是说对象的使用者不直接创建对象，而是将对象创建放到其他地方比如容器或者工厂。但是，对象使用者虽然不创建对象但要使用对象，怎么办？这就需要使用DI像对象注入进来。
其实就是从 ClassA a = new ClassA();--> IA a = new ClassA();-->IA a = Factory.CreateA()/IA a = Factory.CreateA()+反射-->IOC容器，一步步演变而来，目的就是对象使用者和对象尽可能松耦合。

Answer 3

这很简单，如果说你的程序有多个实现，并且根据需要加载的话，那么就可以用配置文件写明需要加载的模块，动态加载。比如说不同的数据库适配版本，每个做一个dll。

Answer 4

最简单的，就把它当万能工厂好了。依赖注入依赖于接口隔离，想搞清楚依赖注入，先得有足够接口隔离的经验。在不使用依赖注入的情况下进行接口隔离的设计和实施，规模稍大一些你就会发现两个问题：一个是理想的情况下，都应该依赖于接口而不是具体实现，那么到底应该在哪里写具体实现的创建过程？另一个是接口A的实现依赖于接口B，接口B的实现依赖于C和D，这个关系可能很复杂，创建一个实现需要大量代码，还可能零散和重复，有没有办法把创建过程简单化？形象一点，通过接口制定规范，接口隔离把软件拆分成了可以根据规范组装的零件。然后使用代码或者配置文件定义一个组装说明书。依赖注入框架来根据这个说明书自动组装。这样对应不同需求，只需要制作新零件，然后改下说明书就好。如果自己做框架给别的开发者使用，还能发现另一个问题：如何提供扩展点，让使用者来扩展功能？
这相当于自己的一些零件是可替换的，使用者根据规范做的新零件可以换掉自带的。框架要把自己说明书的一部分交给使用者来定义。使用了依赖注入，就有了统一的方式。成熟的依赖注入框架的功能还不止这些，比如程序集自动发现、生成动态代理、装饰器模式等等，用好了能提高不少生产力。