依赖注入是什么意思？前端
依赖倒置
在软件设计原则中，有一种重要的思想叫作依赖倒置。它的核心思想是：不能让高层组件依赖底层组件，并且，无论高层组件和底层组件，二者都应依赖于抽象。
那么，这个原则和咱们上面的原则是否矛盾呢？其实并不矛盾。
由于这个原则定义中的“依赖”是指“具体依赖”，而上面定义中的依赖所有指“抽象依赖”。我对这两种依赖的定义以下：数据库
具体依赖——若是P层中有一个或一个以上的地方实例化了Q层中某个具体类，则说P层具体依赖于Q层。后端
抽象依赖——若是P层没有实例化Q层中的具体类，而是在一个或一个以上的地方实例化了Q层中某个接口，则说P层抽象依赖于Q层，也叫接口依赖于Q层。
依赖注入:
咱们设计的分层架构，层与层之间应该是松散耦合的。由于是单向单一调用，因此，这里的“松散耦合”实际是指上层类不能具体依赖于下层类，而应该依赖于下层提供的一个接口。这样，上层类不能直接实例化下层中的类，而只持有接口，至于接口所指变量最终到底是哪个类，则由依赖注入机制决定。
层次划分：
目前，典型的分层架构是三层架构，即自底向上依次是数据访问层、业务逻辑层和表示层。安全
职责划分：
目前，在典型的三层架构中，对层次各自的职责划分并无一个统一的规范，综合现有的成功实践和.NET平台的特殊性，在本文中将三层架构的职责划分以下：网络
数据访问层——负责与数据源的交互，即数据的插入、删除、修改以及从数据库中读出数据等操做。对数据的正确性和有效性不负责，对数据的用途不了解，不负担任何业务逻辑。架构
业务逻辑层——负责系统领域业务的处理，负责逻辑性数据的生成、处理及转换。对流入的逻辑性数据的正确性及有效性负责，对流出的逻辑性数据及用户性数据不负责，对数据的呈现样式不负责。框架
表示层——负责接收用户的输入、将输出呈现给用户以及访问安全性验证。对流入的数据的正确性和有效性负责，对呈现样式负责，对流出的数据正确性不负责，但负责在数据不正确时给出相应的异常信息。
在一个系统框架中一个接口层能够根据不一样的业务对应的有不一样的实现层提供服务。
举个例子 多层架构中,先后端分离的状况下前端只作一些弱逻辑处理，表现层只控制网络请求的输入输出(经过IBLL接口和业务逻辑层依赖),业务逻辑层执行和处理强逻辑,对应不一样的业务能够编写不一样的服务(IBLL接口 提供Bll.pc或者Bll.mobile多套服务)供表现层调用，
数据持久化层通常只作一些原子性的操做
数据持久化层大部分使用关系型数据库,也有使用搜索引擎的还有文件系统,非关系型数据库的
前后端分离