毕业论文：基于.NET平台的分层架构实战.doc文档63页精品范文

对数据的正确性和有效性不负责，对数据的用途不了解，不负担任何业务逻辑。

业务逻辑层负责系统领域业务的处理，负责逻辑性数据的生成处理及转换。

对流入的逻辑性数据的正确性及有效性负责，对流出的逻辑性数据及用户性数据不负责，对数据的呈现样式不负责。

综上所述不矛盾。

因为这个原则定义中的依赖是指具体依赖，而上面定义中的依赖全部指抽象依赖。

我对这两种依赖的定义如下具体依赖如果层中有个或个以上的地方实例化了层中个具体类，则说层具体依赖于层。

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

从这两个定义可以看到，所从这两个定义可以看到，所谓的依赖倒置原则，正是上面提到针对接口编程，而不是针对实现编程，两者在本质上是统的。

抽象依赖如果层没有实例化层中的具体类，而是在个或个以上的地我对这两种依赖的定义如下具体依赖如果层中有个或个以上的地方实例化了层中个具体类，则说层具体依赖于层。

部分内容简介抽象。

那么，这个原则和我们上面的原则是否矛盾呢其实并不矛盾。

因为这个原则定义中的依赖是指具体依赖，而上面定义中的依赖全部指抽象依赖。

我对这两种依赖的定义如下具体依赖如果层中有个或个以上的地方实例化了层中个具体类，则说层具体依赖于层。

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

从这两个定义可以看到，所谓的依赖倒置原则，正是上面提到针对接口编程，而不是针对实现编程，两者在本质上是统的。

综上所述，可以看出，本课题设计的分层架构，应该是这样种架构层架构的各层依次编号为„„，其中层的编号越大，则越处在上层。

架构中仅存在种依赖，即第层接口依赖第层，其中。

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

开放关闭原则开发关闭原则定义为对扩展开放，对修改关闭。

具体到层架构中，可以描述为当层有了个新的具体实现时，它应该可以在不修改其他层的情况下，与此新实现无缝连接，顺利交互。

单归属原则在这个架构中，任何个操作类都应该有单的职责，属于单独的层，而不能同时担负两种职责或属于多个层次实体类及辅助类可以被多个层使用，但它们不属于任何个层，而是存在。

层次划分目前，典型的分层架构是三层架构，即自底向上依次是数据访问层业务逻辑层和表示层。

这种经典架构经历了时间的考验和实践的多次检验，被认为是合理有效的分层设计，所以，在本文中，将沿袭这种经典架构，使用数据访问层业务逻辑层和表示层的三层架构体系。

职责划分目前，在典型的三层架构中，对层次各自的职责划分并没有个统的规范，综合现有的成功实践和平台的特殊性，在本文中将三层架构的职责划分如下数据访问层负责与数据源的交互，即数据的插入删除修改以及从数据库中读出数据等操作。

对数据的正确性和有效性不负责，对数据的用途不了解，不负担任何业务逻辑。

业务逻辑层负责系统领域业务的处理，负责逻辑性数据的生成处理及转换。

对流入的逻辑性数据的正确性及有效性负责，对流出的逻辑性数据及用户性数据不负责，对数据的呈现样式不负责。

表示层负责接收用户的输入将输出呈现给用户以及访问安全性验证。

对流入的数据的正确性和有效性负责，对呈现样式负责，对流出的数据正确性不负责，但负责在数据不正确时给出相应的异常信息。

模块划分及交互设计综合以上分析，可在宏观上将整个系统分为下几个模块实体类模块组实体类的集合，负责整个系统中数据的封装及传递。

数据访问层接口族组接口的集合，表示数据访问层的接口。

业务逻辑层接口族组接口的集合，表示业务逻辑层的接口。

数据访问层模块组类的集合，完成数据访问层的具体功能，实现数据访问层接口族。

业务逻辑层模块组类的集合，完成业务逻辑层的具体功能，实现业务逻辑层接口族。

表示层模块程序及可视元素的集合，负责完成表示层的具体功能。

容器模块负责依赖注入的实现。

辅助类模块完成全局辅助性功能。

各模块间交互关系如下图总体架构图基于平台的分层架构实战四实体类的设计与实现实体类是现实实体在计算机中的表示。

它贯穿于整个架构，负担着在各层次及模块间传递数据的职责。

般来说，实体类可以分为贫血实体类和充血实体类，前者仅仅保存实体的属性，而后者还包含些实体间的关系与逻辑。

我们在这个中用的实体类将是贫血实体类。

大多情况下，实体类和数据库中的表这里指实体表，不包括表示多对多对应的关系表是对应的，但这并不是个限制，在复杂的数据库设计中，有可能出现个实体类对应多个表，或者交叉对应的情况。

在本文的中，实体类和表是对应的，并且实体类中的属性和表中的字段也是对应的。

在看实体类的代码前，先看下系统的工程结构。

图工程结构图如上图所示，在初始阶段，整个系统包括个工程，它们的职责是这样的表示层存放实体类存放和依赖注入及相关的类存放业务逻辑层接口族存放数据访问层接口族存放各种工具类及辅助类这只是个初期架构，主要是将整个系统搭个框架，在后续开发中，将会有其他工程被陆陆续续添加进来。

我们的实体类将放在工程下，这里包括三个文件，分别是管理员实体类留言实体类和评论实体类。

具体代码如下实体类管理员的引用，这个文件在文件包的下。

完成后，在这个工程下新建个文件，名为，这个文件就是设计文件，根据对实体和数据库的设计，编写完整代码如下设计完后，将这个工程编译备用。

创建专用实体类及配置文件在文件包的下，有个程序，打开它，点击按钮，选择刚才编译生成的文件，并在文本框里输入相应的命名空间，这里我们应输入。

然后点击按钮，这时会在底下的文本框里生成专用实体类代码。

在解决方案下新建个工程，用于存放所有数据访问层的实现代码。

在这个工程下新建，将刚才自动生成的代码覆盖掉这个文件的代码，专用实体类就做好了。

另外，需要给工程添加到和的引用，这两个文件都在下。

点击按钮，这时会生成配置代码。

在工程下新建文件，将生成的代码复制到这个文件里保存。

最后还要修改下文件。

增加如下配置代码然后再在节点下增加如下项其中是连接字符串，根据个人不同情况进行修改。

这里使用的是。

因为数据库在上篇中已经创建好了，这里就不需要创建数据库了。

编写转换器这里出现了个矛盾业务逻辑层和表示层需要使用通用的实体类，如，而需要使用专用实体类。

怎么解决这个矛盾呢我这里使用的方法是个我称之为转换器的方法。

即为没个实体写个专门的转换器，实现两种实体类的转换。

这里以管理员实体为例，这个转换器写在工程下的文件中。

具体代码如下实体类转换器管理员由普通管理员实体类转化为专用管理员实体类普通实体类专用实体类由专用管理员实体类转化为普通管理员实体类专用实体类普通实体类实现数据访问层做完上述工作，我们就可以来实现数据访问层了。

借助于框架的支持，我们可以非常方便的使用方式访问数据库。

关于的细节，这里不再赘述，以管理员为例，具体代码如下插入管理员管理员实体类是否成功删除管理员欲删除的管理员的是否成功