基于.NET平台的分层架构设计

   记录下软件架构与设计模式课上老师讲的一个基于.NET平台的分层架构设计例子。

   从上个暑假自己研究着做论坛，然后上学期做HS的选课系统，做WEB课程设计，接触了不是WEB开发的东西。前面两个用的j2ee，后面一个用的.NET。其实真正做出来的只有选课系统的一小部分，呃，其他的就不说了，不想说。但是接触这些东西之后，刚开始觉得很乱，因为没有系统的学习这些东西就开始拿来用了，后面才知道还有架构什么的。现在特别想好好理解下这些东西，至少得清楚的明白自己之前用的那些东西是怎么回事嘛。正好课上讲了这么个例子，但是是.net的，把PPT上有价值的内容拷上来，学习用。列出的是主要的步骤。

  简单的留言本系统NGuestBook

1.需求分析与数据库设计

 需求分析描述：

1.任何访问者可以进行留言，留言完成后，不会立即显示正文，而是要经过管理员验证后才可显示。2.任何访问者可以对留言发表评论，未通过验证的留言不可以评论。3.管理员可以对留言进行回复（这个回复不同于评论，是直接显示在正文下面，而且是一个留言只能有一个回复），并可对留言与评论实行删除，以及对留言进行通过验证操作。4.管理员分为超级管理员和普通管理员。超级管理员只有一个，负责对普通管理员实行添加、删除操作。普通管理员可有多个，负责对留言的管理，并可以修改自己的登录密码。

数据库设计

 本项目的实体有：管理员（不包括超级管理员）、留言、评论

本项目的关系有：留言与评论间的一对多关系

数据库表的设计：管理员表（TAdmin）留言表（TMessage）评论表（TComment）

2.架构概要设计

层次划分：沿袭经典的三层架构，即自底向上依次为数据访问层、业务逻辑层和表示层。  

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

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

  表示层——负责接收用户的输入、将输出呈现给用户以及访问安全性验证。对流入的数据的正确性和有效性负责，对呈现样式负责，对流出的数据正确性不负责，但负责在数据不正确时给出相应的异常信息。

系统的工程结构：

Web——表示层

Entity——存放实体类

Factory——存放和依赖注入及IoC相关的类

IBLL——存放业务逻辑层接口族

IDAL——存放数据访问层接口族

Utility——存放各种工具类及辅助类

3. 实体类的设计与实现

 实体类放在Entity工程下，包括三个文件：

AdminInfo.cs 管理员实体类、MessageInfo.cs留言实体类、CommentInfo.cs评论实体类

4. 接口的设计与实现

 

接口包括：数据访问层接口、业务逻辑层接口

接口设计步骤：由需求分析，列出主要的UI；分析各个UI需要什么业务逻辑支持，从而确定业务逻辑层接口；分析业务逻辑层接口需要何种数据访问操作，从而确定数据访问层接口。

 

5.依赖注入机制及IoC的设计与实现 

 

  分层架构层间是松散耦合的。因为是单向单一调用，这里的“松散耦合”实际是指上层类不能具体依赖于下层类，而应该依赖于下层提供的接口。上层类不能直接实例化下层中的类，而只持有接口，至于接口所指变量最终究竟是哪一个类，则由依赖注入机制决定。依赖注入的理论基础是：Abstract Factory设计模式。

6.数据访问层实现

7.业务逻辑层的实现

8.表示层的实现 

   大概的框架罗列出来了，貌似不太详细，准备写上来时才发现内容有点多，而且有些没有必要写。依赖注入机制不太理解，有时间好好看下。理解了再写上来。