基于.NET平台的分层架构实战（三）——架构概要设计

Love The Way You Lie 2022-07-15 09:22 214阅读 0赞

出处：[http://www.cnblogs.com/leoo2sk/archive/2008/06/17/1223559.html][http_www.cnblogs.com_leoo2sk_archive_2008_06_17_1223559.html]

## [基于.NET平台的分层架构实战（三）——架构概要设计][http_www.cnblogs.com_leoo2sk_archive_2008_06_17_1223559.html] ##

2008-06-17 10:25 by T2噬菌体, 13112 阅读, 33 评论, [收藏][Link 1], [编辑][Link 2]

本文主要是对将要实现的架构进行一个总体的描述，使朋友们对这个架构有个宏观上的认识。这篇文章理论性的东西会偏多一点，从下篇开始，将进行实际项目的开发。这篇文章的许多内容摘自我的毕业论文。  
  
**架构基本原则：**  
这里，将描述一些在这个架构设计中的基本原则，其中很多都是经典的设计原则，不过针对分层架构的特点，用我自己的语言进行了描述。其中也有我自己提出的原则。

**逐层调用原则及单向调用原则**  
现在约定将N层架构的各层依次编号为1、2、…、K、…、N-1、N，其中层的编号越大，则越处在上层。那么，我们设计的架构应该满足以下两个原则：

1.第K（1<K<=N）层只准依赖第K-1层，而不可依赖其他底层。

2.如果P层依赖Q层，则P的编号一定大于Q。

其中第一个原则，保证了依赖的逐层性，及整个架构的依赖是逐层向下的，而不能跨层依赖。第二个原则，则保证了依赖的单向性，及只能上层依赖底层，而不能底层反过来依赖上层。

**针对接口编程，而不是针对实现编程**  
这里所指的接口，不是特指编程语言中的具体语言元素（如C\#中由Interface定义的语言接口），而是指一种抽象的，在语义层面上起着接合作用语义体。它的具体实现，可能是接口，可能是抽象类，甚至可能是具体类。  
我认为，从不同的视角，接口可以有以下两种定义：

1.接口是一组规则的集合，它规定了实现本接口的类或接口必须拥有的一组规则。体现了自然界“如果你是……则必须能……”的理念。

2.接口是在一定粒度视图上同类事物的抽象表示。注意这里我强调了在一定粒度视图上，因为“同类事物”这个概念是相对的，它因为粒度视图不同而不同。

具体到N层架构中，针对接口编程的意义在部分上是这样的：  
现仍约定将N层架构的各层依次编号为1、2、…、K、…、N-1、N，其中层的编号越大，则越处在上层，那么第K层不应该依赖具体一个K-1层，而应该依赖一个K-1层的接口，即在第K层中不应该有K-1层中的某个具体类。

**依赖倒置原则**  
在软件设计原则中，有一种重要的思想叫做依赖倒置。它的核心思想是：不能让高层组件依赖底层组件，而且，不管高层组件和底层组件，两者都应依赖于抽象。  
那么，这个原则和我们上面的原则是否矛盾呢？其实并不矛盾。  
因为这个原则定义中的“依赖”是指“具体依赖”，而上面定义中的依赖全部指“抽象依赖”。我对这两种依赖的定义如下：

具体依赖——如果P层中有一个或一个以上的地方实例化了Q层中某个具体类，则说P层具体依赖于Q层。

抽象依赖——如果P层没有实例化Q层中的具体类，而是在一个或一个以上的地方实例化了Q层中某个接口，则说P层抽象依赖于Q层，也叫接口依赖于Q层。

从这两个定义可以看到，所谓的依赖倒置原则，正是上面提到针对接口编程，而不是针对实现编程，两者在本质上是统一的。  
综上所述，可以看出，本课题设计的分层架构，应该是这样一种架构：

1.N层架构的各层依次编号为1、2、…、K、…、N-1、N，其中层的编号越大，则越处在上层。

2.架构中仅存在一种依赖，即第K层接口依赖第K-1层，其中1<K<=N。

**封装变化原则**  
封装变化的原则定义为：找出应用中可能需要变化之处，把它们独立出来，不要和那些不需要变化的代码混杂在一起。

**开放-关闭原则**  
开发-关闭原则定义为：对扩展开放，对修改关闭。  
具体到N层架构中，可以描述为：当某一层有了一个新的具体实现时，它应该可以在不修改其他层的情况下，与此新实现无缝连接，顺利交互。

**单一归属原则**  
在这个架构中，任何一个操作类都应该有单一的职责，属于单独的一层，而不能同时担负两种职责或属于多个层次（实体类及辅助类可以被多个层使用，但它们不属于任何一个层，而是独立存在）。  
  
**层次划分：**  
目前，典型的分层架构是三层架构，即自底向上依次是数据访问层、业务逻辑层和表示层。  
这种经典架构经历了时间的考验和实践的多次检验，被认为是合理、有效的分层设计，所以，在本文中，将沿袭这种经典架构，使用数据访问层、业务逻辑层和表示层的三层架构体系。  
  
**职责划分：**  
目前，在典型的三层架构中，对层次各自的职责划分并没有一个统一的规范，综合现有的成功实践和.NET平台的特殊性，在本文中将三层架构的职责划分如下：

数据访问层——负责与数据源的交互，即数据的插入、删除、修改以及从数据库中读出数据等操作。对数据的正确性和有效性不负责，对数据的用途不了解，不负担任何业务逻辑。

业务逻辑层——负责系统领域业务的处理，负责逻辑性数据的生成、处理及转换。对流入的逻辑性数据的正确性及有效性负责，对流出的逻辑性数据及用户性数据不负责，对数据的呈现样式不负责。

表示层——负责接收用户的输入、将输出呈现给用户以及访问安全性验证。对流入的数据的正确性和有效性负责，对呈现样式负责，对流出的数据正确性不负责，但负责在数据不正确时给出相应的异常信息。  
  
**模块划分及交互设计：**  
综合以上分析，可在宏观上将整个系统分为一下几个模块：  
实体类模块——一组实体类的集合，负责整个系统中数据的封装及传递。  
数据访问层接口族——一组接口的集合，表示数据访问层的接口。  
业务逻辑层接口族——一组接口的集合，表示业务逻辑层的接口。  
数据访问层模块——一组类的集合，完成数据访问层的具体功能，实现数据访问层接口族。  
业务逻辑层模块——一组类的集合，完成业务逻辑层的具体功能，实现业务逻辑层接口族。  
表示层模块——程序及可视元素的集合，负责完成表示层的具体功能。  
IoC容器模块——负责依赖注入的实现。  
辅助类模块——完成全局辅助性功能。  
  
各模块间交互关系如下：

![20161111115027391][]  
图3.1、总体架构图

[http_www.cnblogs.com_leoo2sk_archive_2008_06_17_1223559.html]: http://www.cnblogs.com/leoo2sk/archive/2008/06/17/1223559.html
[Link 1]: http://www.cnblogs.com/leoo2sk/archive/2008/06/17/1223559.html#
[Link 2]: https://i.cnblogs.com/EditPosts.aspx?postid=1223559
[20161111115027391]: /images/20220715/3ef4350b21814814aac92c793d4d0541.png