最近在求职，耽搁了，对于应届生来讲想找个大数据相关的工作何其困难。。。
所以在填充一些自己不足之处，希望与君共勉。
开发过程中，如果发现客户程序依赖某个(或某类)对象，我们就通常会对他们进行一次抽象，形成抽象类、接口。这样，客户程序就可以摆脱所依赖的具体类型。
那么“谁”担任这个重担呢？其实，很多时候创建型模式可以轻易的解决这个问题。但如果设计的不是具体业务逻辑，而是公共库/框架，这时候很多半成品的外部类型实例会在我们的管理下执行，如何把这些外部类型所需的抽象类型传给他们就成了新问题。
这个场景也就是常说的“控制反转”，IOC：Inverse of Control；框架程序与抽象类型的调用关系就像常说的好莱坞规则“Don’t call me,I’ll call you”，即，由IOC容器帮对象找相应的依赖对象并注入，而非对象主动去找。
IOC 容器控制了对象，主要控制了外部资源获取(不只是对象，包括文件等)。
IOC 反转，由容器帮我们查找及注入依赖对象，对象是被动的接受依赖对象，所以是反转。
"依赖注入"的方式：将加工好的抽象类型实例“注入”到客户程序中。
IOC对编程的改变是在思想上，发生了“主从换位”的变化。
构造注入方式又称“构造子注入”、“构造函数注入”，这种注入方式就是在构造函数的执行过程中，通过Assembler或其他机制把抽象类型作为参数类型作为参数传递给客户类型。这种方式虽然相对其他方式有些粗糙，而且仅在构造过程中通过“一锤子买卖”的方式设置好，但很多时候我们设计上正好就需要这种“一次性”的注入方式。
设值注入是通过属性方法赋值来实现的，set(…)。
相对构造方式而言，设值注入给了客户类型后续修改的机会，它比较适合客户类型实例存活时间较长的情景。
接口注入是将抽象类型的入口以方法定义在一个接口中，如果客户类型需要获得这个方法，就需要以实现这个接口的方式完成注入。
实际上接口注入有很强的侵入性，除了要求客户类型增加前面两种方式所需实现的代码外，还必须显式的定义一个新的接口并要求客户类型实现它，
在Assembler和客户类型中选择，为了客户对象影响最小，我们只好在Assembler上下功夫，因为他的职责就是负责组装。反而言之，如果注入过程还需要修改客户程序，那我们就没必要去用“依赖注入”了。
但是在实际项目中，由于属性注入处理不好会导致运行效率低(每次实例化对象都需要映射)和对客户端的侵略性，我们要慎重使用。
构造方式
他的注入是一次性的，当客户类型构造的时候就确定了
他适合生命期不长、在其存续期间不需要重新适配的对象
设值方式
一个很灵活的实现方式
对于生命周期较长的客户而言，可以在运行过程中随时注入
属性方式
作为注入方式具有入侵性，很大程度上他适于需要同时约束一批客户类型的情况
他本身实现相对复杂一些，但客户类型使用的时候非常方便–“打标签”即可
接口方式
作为注入方式具有入侵性，很大程度上他适于需要同时约束一批客户类型的情况
但是C#中使用泛型可以减少其入侵性
注入方式
具有入侵性，很大程度上他适于需要同时约束一批客户类型的情况
但是C#中使用泛型可以减少其入侵性
