what is ioc:
控制注入，是一种设计模式
the benefits of using this:
降低耦合度
什么是DI
什么是依赖？
当一个类需要另一个类协作来完成工作的时候就产生了依赖
例如：在日志处理类中，需要将日志写入数据库，这是就需要一个写入数据库的相关类，从而就产生了依赖
按照抽象设计:
LogContext -> IWriteLog -> WriteDbLog
什么是注入？
依旧是上面那个例子，既然产生了依赖，就需要获得这个依赖的对象
step1：在LogContext定义一个 IWriteLog 的属性
step2: 在构造函数中直接实例化这个属性 -
考虑到业务变动，你不应该自己创建它而是应该由你的调用者给你
(2) step2:在构造函数中定义相应的参数，让调用者传入
把依赖的创建丢给其它人，自己只负责使用，其它人丢给你依赖的这个过程理解为注入。
什么是反转?
本应该由LogContext控制依赖的实现，但却由调用者注入，就产生了反转
什么是容器？
为什么要用容器？
上面这种情况控制是反转了，依赖的创建也移交到了外部。
但若是程序中存在100个这种地方，岂不是在100个地方进行注入，依赖太多，也不便于进行管理
所以需要一个地方统一管理系统中所有的依赖，这便是容器的诞生
容器负责两件事情：
• 绑定服务与实例之间的关系
• 获取实例，并对实例进行管理（创建与销毁）
为什么要使用DI？
以上例为说明
不使用DI时：
1.增加耦合度，日志的处理在日志中写入，当需要写入数据库时，会增加数据库相关的依赖，当写入磁盘时，又会增加磁盘的相关依赖
2.增加维护成本，当一个类的内容涉及过广时，很难察觉到真正需要关注的地方。
使用DI时：
1.降低耦合，一层依赖(抽象依赖),简单易用，降低耦合
2.降低维护成本，调整写入数据库逻辑，便只需要关注写入数据库的内容，调整写入磁盘也是如此
3.便于扩展，当调整写入缓存时，只需外部更改注入类，无效考虑日志处理类的做法
for example:
图解
常见场景
request --> UI层 --> response
小型UI层:
获取dal/dbcontext
执行操作
三层UI业务:
获取 service
获取service关联的dal
执行操作
多层业务:
获取 service
获取上述关联层实例
获取上述关联层实例
获取上述关联层实例...
执行操作
flow
未使用IOC vs 使用了IOC
<IOC>
1. UI只与容器关联
2. 容器与对象之间通过标识关联(通常是泛型type+抽象)
3. 业务调整时，无需考虑相关层的业务关系，只需维护本层业务
4. 当业务内容过多时，可以自行建立层级标准来维护标识的准确性
5. 简单易用,无需考虑过多元素
<无IOC时>
1. UI与最低层关联
2. 最低层与上层层层关联
3. 业务调整时，应考虑相关层的使用
4. 当业务内容过多时，阅读业务含义需要访问所有关联层方可理解
5. 复杂关联，容易出现代码重复，即便抽象也难以维护。。。
emm... 总结太多了，熟悉得不能再熟悉了。
author:monster
since:12/11/2018 3:26:09 PM
direction:ioc