浅谈.NET,C#三层架构（自己总结）

 三层架构

• 常见架构：

1. 　三层（经典）
2. MVC
3. MVVM
4. MVP

 

• 开发中常见的23种设计模式：

创建型模式，共五种：工厂方法模式、抽象工厂模式、单例模式、建造者模式、原型模式。

结构型模式，共七种：适配器模式、装饰器模式、代理模式、外观模式、桥接模式、组合模式、享元模式。

行为型模式，共十一种：策略模式、模板方法模式、观察者模式、迭代子模式、责任链模式、命令模式、备忘录模式、状态模式、访问者模式、中介者模式、解释器模式。

• 设计模式的六大原则

1、开闭原则

2、里氏代换原则

3、依赖倒转原则

4、接口隔离原则

5、迪米特法则（最少知道原则）

6、合成复用原则

 

• 程序与程序交互方式

1.引用命名空间

2.文件（IO，servile），文件流，序列化

3.DB数据库

4.web请求（Ajax）（Socket）（HTTPRequest 提交方式：get，post）

 

---

 

链接1（百度百科）：

https://baike.baidu.com/item/%E4%B8%89%E5%B1%82%E6%9E%B6%E6%9E%84/11031448?fr=aladdin

连接2（必看）：http://blog.csdn.net/hanxuemin12345/article/details/8544957/

高内聚低耦合：

https://baike.baidu.com/item/%E9%AB%98%E5%86%85%E8%81%9A%E4%BD%8E%E8%80%A6%E5%90%88

 

---

 

1.概念：

三层架构(3-tier architecture) 通常意义上的三层架构就是将整个业务应用划分为：

• 界面层UI（User Interface layer）
• 业务逻辑层BLL（Business Logic Layer）
• 数据访问层DAL（Data access layer）

区分层次的目的即为了“高内聚低耦合”

任何一层发生变化都不会影响到另外一层！！！

 

1：数据访问层：主要是对非原始数据的操作层，是对数据库的操作，具体为业务逻辑层或表示层提供数据服务

2：业务逻辑层：主要是针对具体的问题的操作，对数据业务逻辑处理

3：界面层：展示层，交互界面，主要表示WEB方式，也可以表示成winform方式。

 

 

2.高内聚低耦合：

概念

　　耦合性：也称块间联系。指软件系统结构中各模块间相互联系紧密程度的一种度量。模块之间联系越紧密，其耦合性就越强，模块的独立性则越差。模块间耦合高低取决于模块间接口的复杂性、调用的方式及传递的信息

　　内聚性：又称块内联系。指模块的功能强度的度量，即一个模块内部各个元素彼此结合的紧密程度的度量。若一个模块内各元素（语名之间、程序段之间）联系的越紧密，则它的内聚性就越高。

　　耦合：一个软件结构内不同模块之间互连程度的度量。

　　低耦合，粗浅的理解是：一个完整的系统，模块与模块之间，尽可能的使其独立存在。

　　高内聚是指一个软件模块是由相关性很强的代码组成，只负责一项任务，也就是常说的单一责任原则。

 

3.优缺点：

优点

1、开发人员可以只关注整个结构中的其中某一层；

2、可以很容易的用新的实现来替换原有层次的实现；

3、可以降低层与层之间的依赖；

4、有利于标准化；

5、利于各层逻辑的复用。

6、结构更加的明确

7、降低维护成本和维护时间

缺点

1、降低了系统的性能。这是不言而喻的。如果不采用分层式结构，很多业务可以直接造访数据库，以此获取相应的数据，如今却必须通过中间层来完成。

2、有时会导致级联的修改。这种修改尤其体现在自上而下的方向。如果在表示层中需要增加一个功能，为保证其设计符合分层式结构，可能需要在相应的业务逻辑层和数据访问层中都增加相应的代码。

3、增加了开发成本。

 

4.实体层（Entity）：（看连接2）

 

Entity(实体层)：它不属于三层中的任何一层，但是它是必不可少的一层

实体类库（Model），主要存放数据库中的表字段。

 

4，每一层（UI—>BLL—>DAL）之间的数据传递（单向）是靠变量或实体作为参数来传递的，这样就构造了三层之间的联系，完成了功能的实现。

但是对于大量的数据来说，用变量做参数有些复杂，因为参数量太多，容易搞混。比如：我要把员工信息传递到下层，信息包括：员工号、姓名、年龄、性别、工资．．．．用变量做参数的话，那么我们的方法中的参数就会很多，极有可能在使用时，将参数匹配搞混。这时候，如果用实体做参数，就会很方便，不用考虑参数匹配的问题，用到实体中哪个属性拿来直接用就可以，很方便。这样做也提高了效率。

 

（注：这里为什么说可以暂时理解为每个数据表对应一个实体？？答：大家都知道，我们做系统的目的，是为用户提供服务，用户可不关心你的系统后台是怎么工作的，用户只关心软件是不是好用，界面是不是符合自己心意。用户在界面上轻松的增、删、改、查，那么数据库中也要有相应的增、删、改、查，而增删改查具体操作对象就是数据库中的数据，说白了就是表中的字段。所以，将每个数据表作为一个实体类，实体类封装的属性对应到表中的字段，这样的话，实体在贯穿于三层之间时，就可以实现增删改查数据了）

综上所述:三层及实体层之间的依赖关系:

 

5.代码：

三层架构简单代码： http://blog.csdn.net/zhgl7688/article/details/43669463#comments