三层架构标准

三层架构标准

微软的.Net平台给应用程序开发提供了一个非常好的基础系统平台，但是，如何在这个系统平台上构建自己的应用系统，还需要我们针对应用系统的特点，构建自己的应用系统框架（Framework）。笔者在应用.Net 开发系统的过程中，结合多年的开发经验，设计了一套.Net下的应用系统开发框架，以及相应的中间件和开发工具，已经在多个项目中和软件产品中应用，取得了很好的效果。

系统的基本结构

对于典型的三层应用系统来说，通常可以把系统分成以下三个层次：

a.数据库层

b.用户界面层

c.应用服务层

对于应用系统来说，在这三个层次中，系统的主要功能和业务逻辑在应用服务层进行处理，对于系统框架来说，主要处理的也是这个层次的架构。

对于应用服务层来说，需要处理以下几个方面的问题：

数据的表示方式，也就是实体类的表示方式，以及同数据库的对应关系，即所谓的O-R Map的问题。在框架中，这个部分位于数据实体层

数据的存取方式，也就是实体类的持久化问题，通常采用数据库来永久存储数据实体，这就需要解决同数据库的交互问题。在框架中，这个部分位于实体控制层

业务逻辑的组织方式。在面向对象的系统中，业务逻辑是通过对象间的消息传递来实现的。在这个部分，为了保证逻辑处理的正确性和可靠性，还必须支持事务处理的能力。在框架中，这个部分位于业务规则层业务服务的提供方式。为了保证系统的灵活性和封装性，系统必须有一个层来封装这些业务逻辑，向客户端提供服务，同时作为系统各个模块间功能调用的接口，保证系统的高内聚和低耦合性。这里的客户指的不是操作的用户，而是调用的界面、其他程序等。Web层（https://www.360docs.net/doc/ec12055621.html,页面）通常只同这个部分交互，而不是直接调用业务逻辑层或者数据实体的功能。在框架中，这个部分位于业务外观层。

将系统划分成这么多层次，其好处是能够使得系统的架构更加清晰，并且，系统的层次划分的清晰，就意味着每个层次完成的功能就比较单一，也就意味着这些功能的代码是有规律可循的，也就意味着我们可以开发一些工具来生成这些代码，从而减少代码编写的工作量，使得开发人员可以将更多的精力放到业务逻辑的处理上。正是基于这个想法，我们开发了针对这个框架的开发工具，在实际的使用，能够减少很多代码的编写量，效果非常好。同时，为了应用服务层更好的工作，我们设计了一个支持这个框架的应用系统中间件，现在，除了本公司，也已经有多家其他公司在试用这个中间件系统。

数据库服务层

数据库用于对象的持久化储存，也即数据的存放。数据库层采用关系型数据库。系统可以支持各种主流的关系型数据库系统，包括SQL Server7.0以上版本和Oracle8以上版本的数据库。

框架提供了一套类库，作为客户端同数据库之间交互的中介，很大一部分功能就是要对两者之间的交互进行控制，并提供一系列提高性能和安全性的服务。

用户界面层

用户界面层用于同用户的交互，可以是Web浏览器用户或传统客户端，但是从系统的可维护性等方面考

虑，一般使用Web浏览器为客户端。利用这套框架和开发工具，可以构建纯Web客户端的应用系统，大大方便系统的维护和部署。

数据实体层

这个层用于封装实体类的数据结构，用于映射数据库的数据，表现实体类的类结构和数据。在开发过程中，我们充分感觉到了.Net中DataSet数据对象的强大功能，因此，在O-R Map上，我们实际上是通过DataSet来实现的。

数据实体层包含三个方面的内容：

1）核心类库定义了EntityData类，这个类继承了DataSet作为所有实体类的框架类，定义了各个实体类的一般结构，至于每个实体类具体的结构，在运行时刻由下述办法确定：

2）实体类的定义通过XML文件来确定，该XML文件符合JIXML对象实体描述语言的规范（注：JIXML 是迪讯开发的对象—实体映射语言），用于确定实体类的结构。例如，一个关于订单的实体类的定义可能类似于下面的结构：

3）实体类的结构由一系列的类构造器在运行时刻，根据上述规范制定的XML来生成。这些类构造器实现IClassBuilder接口。系统核心类库预定义了一些标准的Builder，一般情况下，直接使用这些标准的Builder就可以了。

类构造器采用的类构造工厂的设计模式，如果使用者觉得标准的Builder不能满足要求，也可以扩展IClassBuilder接口，编写自己的类构造器，然后在系统配置文件中指明某各类的类构造器的名称即可。

系统同时提供了实体对象缓存服务。通过上述方式产生的实体对象可以被缓存，这样，在第二次调用该对象时，可以从缓存中读取，而不用从头重新生成，从而大大提高了系统的性能。

数据实体层采用这种设计模式具有以下优点：

1.实体类定义XML文件可以通过工具来自动生成，减轻开发工作量。

2.在修改实体类的定义时，如果修改的部分不涉及到业务逻辑的处理，只需要修改XML文件就可以了，不用修改其它程序和重新编译。

3.系统提供的实体对象缓存服务可以大大提高了系统的性能。

4.类构造工厂的设计模式大大提高了系统的灵活性。

数据访问层

这个层次提供对数据库操作的服务，通常执行以下一些操作：

1.连接数据库

2.执行数据库操作

3.查询数据库，返回结果

4.维护数据库连接缓存

5. 数据库事务调用

框架的类库中包含了数据访问服务，封装了常用的对各种数据库的操作，可以访问不同类型的数据库，使得应用系统在更换数据库时，不用修改原有的代码，大大简化了开发和部署工作。

数据访问服务还维护数据库连接缓存，提高系统性能，以及对数据库事务调用的服务。

数据访问服务在核心类库中主要通过DBCommon类来提供对数据访问功能调用的服务。

实体控制层

实体控制层用于控制数据的基本操作，如增加、修改、删除、查询等，同时为业务规则层提供数据服务。

业务规则层

业务规则层包含各种业务规则和逻辑的实现业务规则层的设计通常需要进行很好的建模工作。业务规则的建模，一般采用UML来进行。可以使用UML的序列图、状态图、活动图等来为业务规则建模。这个部分的工作，通常通过一系列的类之间的交互来完成。例如，在一个库存系统的入库单入库操作中，除了需要保存入库单外，在这个之前，还必须对入库单涉及的产品的数量进行修改

业务外观层

业务外观层为 Web 层提供处理、浏览和操作的界面。业务外观层用作隔离层，它将用户界面与各种业务功能的实现隔离开来。

业务外观层只是将已经完成的系统功能，根据各个模块的需要，对业务规则进行高层次的封装。

框架没有规定采用在业务外观层采用何种实现方式，但是建议使用Web Service来提供服务。采用IIS 为Web服务器，可以很方便的部署Web Service。

Web层

Web 层为客户端提供对应用程序的访问。Web 层由 https://www.360docs.net/doc/ec12055621.html, Web 窗体和代码隐藏文件组成。Web 窗体只是用 HTML 提供用户操作，而代码隐藏文件实现各种控件的事件处理。

通常，对于数据维护类型的https://www.360docs.net/doc/ec12055621.html, Web 窗体和控件事件处理代码，我们提供了工具来生成，减轻开发工作量。

除了上述6个逻辑层以外，系统通常还包括一个系统配置项目，提供应用程序配置和跟踪类。

框架中间件提供的主要服务

框架中间件提供一系列的服务，以实现对构筑其上的应用软件的支持。

O-R Map：对象—关系数据库映射服务

这部分完成应用程序中的实体对象同关系型数据库的映射，主要为数据实体层提供服务。

在这个部分中，定义了JIXML实体—对象映射语言。这是我们开发的一种使用XML来描述对象—实体间的映射关系的规范语言，开发者可以使用它来描述对象—实体间的映射关系。开发者也可以直接扩展IClassBuilder接口，手工完成对象—实体间映射关系的代码。系统在运行时刻，会根据配置文件的设置，调用实体类的构造器，动态构造出实体对象的结构。

Database Access：数据库访问服务

这个部分提供对数据库访问的服务。在这个框架上构建的应用软件系统，不直接操纵数据库，而是通过类库提供的数据访问服务来进行。数据库访问服务作为应用程序同数据库之间的中介者，能够有效防止对数据库的不安全操作。

数据库访问服务同时提供了对数据库库事务处理的调用方法，开发者可以很方便的通过数据库访问服务调用数据库的事务处理功能。

DML Search：数据操纵语句查询服务

在系统架构中，对数据库进行操作的SQL语句不在程序中硬编码，而是同数据实体层的实体类结构一样在XML文件中描述，其结构符合JIXML规范。这些操纵语句中的基本部分，如数据的插入、删除、修改、查询等语句，可以通过我们自己开发的工具生成。这样，在系统的便于修改性和灵活性上能够得到很大的提高。这样一来，系统必须提供这些数据操纵语句的查询服务。核心类库提供了在XML文件中查找这些数据操纵语句和相关参数的服务。

Entity Buffer&Search：实体对象缓存&查找服务

系统中的实体对象在第一次创建后，就被系统缓存起来，当系统第二次需要访问该对象时，不需要再从头创建这个对象，而只需要从缓存中取出即可。这就是迪通提供的实体对象缓存服务。同这个服务相关联的是实体对象的查找服务，即从这些缓存的实体对象中寻找相应的实体对象的服务。

Transaction：事务处理服务

我们充分利用Windows COM+事务处理机制的强大功能，使在应用程序能够充分使用事务处理的功能，保证应用系统的稳定性和可靠性。

当某个类需要使用事务处理功能时，首先使该类继承System.EnterpriseServices名称空间下的ServicedComponent类，然后使用如下方式申明该类使用的事务类型：

[Transaction(TransactionOption.Required)]。系统在该类第一次被调用时，自动在COM+服务中注册中该类，使得应用程序可以使用COM+的事务处理功能。

系统支持如下几种事务处理类型：

成员名称

说明

Disabled

忽略当前上下文中的任何事务。

NotSupported

使用非受控事务在上下文中创建组件。

Required

如果事务存在则共享事务，并且如有必要则创建新事务。

RequiresNew

使用新事务创建组件，而与当前上下文的状态无关。

Supported

如果事务存在，则共享该事务。

核心类库概要说明

在框架的核心类库中，我们提供了以下核心类和接口：

1.EntityData：定义实体类的通用结构

2. IClassBuilder：定义实体类结构构造的结构。迪通中预定义了根据这个接口实现的几个标准类：

AbstractClassBuilder、SingletableClassBuilder、ThickClassBuilder、StandardClassBuilder。这些Builder通过ClassBuilderFactory进行管理。

3. IEntityDAO：定义实体控制类的接口

4. EntityDataManager：提供对所有实体类的缓存管理和查找服务

5.DBCommon：封装数据库操作

6.ApplicationConfiguration：记录系统配置

7.SqlManager：管理系统的SQL语句及其参数。

开发人员在利用迪通进行二次开发时，只需要引入提供的Jobsinfo.dll这个动态链接库就可以充分利用以上编程接口的功能了。

我介绍我们开发的一个.Net下应用软件系统的框架，我将介绍我们即将开发的人力资源管理系统的。现在就按照这个简化的工程来具体谈谈各个部分的设计策略和框架的使用，从中也可以管窥整个系统的设计模式。

这个工程主要功能是人才数据库存的入库，以及相应的人才资料维护的辅助功能。因为工程的功能比较一目了然，而本文的主要目的是说明软件的设计策略，因此，对于涉及到需求的Use Case等内容就不会加以论述了。

静态建模部分（数据实体层的设计）

在这个案例中，主要涉及到人才和入库单两个对象，当然，还有一些辅助对象，如入库单的明细等。整个

部分的静态模型可以用类图表示如下：

相应的，数据库的设计如下：

对象的粒度

现在，我们要做详细的实体类的设计了，也就是将数据库映射到程序的实体类中。

在考虑实体对象的设计时，“对象的粒度”是一个需要仔细考虑的问题，实体对象按照对象的粒度，通常可以分成所谓的“粗粒度对象”和“细粒度对象”。在J2EE中使用EntityBean为实体类作设计时，我们总是尽量将实体对象建模成粗粒度的对象，因为EntityBean是非常耗费资源的，系统中如果存在大量的细粒度对象，会在很影响系统的性能。而在J2EE中，粗粒度对象的设计也是一个需要一定技巧的工作。

在我们设计的框架中，由于在O-R Map部分充分利用了DataSet的强大功能，使得不论是粗粒度对象，还是细粒度对象，我们都采用了相同的处理方式，在对象粒度的设计方面能够得到一定的简化，对象粒度的粗细也不会对系统性能造成太大的影响。

在这几具体案例中，很明显，对于ProductType和Product的结构比较简单，在对他进行操作时，我们通常只涉及到一张表。虽然，对于Product来说，在对其进行查询的时候，需要知道人才类型的时候，会涉及到ProductType表，但是，在大部分的增加、修改、删除的操作中，我们都只对Product表进行操作，因此，我们把这两个对象都设计成细粒度对象。Product类的XML描述文件如下（删去了Sql语句部分）：

与Product不同的是，入库单是一个相对复杂的对象，他包含了自身的一些信息，还有一些明细资料。实际上，入库单的明细也是入库单的一个组成部分，当我们在处理入库单的时候，我们总是会同时处理入库单的明细，入库单和他的明细是不可分的。如果采用传统的O-R Map方法来处理入库单（包含明细），我们通常没有办法用一个简单的类来对其进行描述，在采用我们的这个框架来处理时，我们同样也不能在DataSet中用一个单独的DataTable来描述，同时，在处理入库单时，我们在数据库中也会涉及到多个表的操作。在这种情况下，我们将入库单连同他的明细一起设计成一个“粗粒度对象”。所幸的是，这种设计同细粒度对象的设计差别不大。读者可以仔细比对两个XML文件的不同，了解对于不用粒度的对象的设计策略。

这样，在运行的过程中，我们通过如下方式得到一个入库单对象时，在entity实例对象中，实际上包含了InDepotForm和InDepotFormDetail两个DataTable。

这个部分的实体描述的XML文件，都是通过我们开发的工具生成的，因此，在开发的过程中，在这个部分，我们没有花太多的代码编写时间，这些XML文件，在数据库设计完成后，几乎是一夜间就完成了。

数据访问部分（实体控制层的设计）

解决了数据实体的设计问题后，我们就要处理同数据库的交互部分。这个部分的类实现IEntityDAO接口。这个接口在《一》文中已经做了介绍。这个部分的代码是很有规律的，我们设计的工具能够生成所有基本的增、删、改、查的方法，当然，对于一些复杂的查询方法，还是需要自己再补充的。在《一》文中，我已经介绍了人才的数据访问的类的结构，下面再看一下入库单的数据访问类的结构，应该对这个部分的结构有一个更好的理解，毕竟代码是最能够说明问题的。因为代码比较长，所以只保留了新增入库单的代码，其余的代码各位可以在示例工程中找到。

业务逻辑的处理

有了上面的基础，我们很容易将这些类进行组合，构建我们的业务处理功能。在这个系统中，涉及到复杂业务处理的部分只有入库单入库这个功能，这个功能我们封装在Wharehouse类中，其过程可以用序列图表示如下：

相应的程序代码和注解如下，在这里，我们使用了事务处理，因此，Wharehouse类继承了System.EnterpriseServices.ServicedComponent：

//设置事务处理类型

[Transaction(TransactionOption.Required)]

//继承ServicedComponent，以支持使用Windows的Transaction Service

public class Wharehouse : System.EnterpriseServices.ServicedComponent

{

public Wharehouse(){}

//入库的业务逻辑代码

public void StoreIntoWarehouse(EntityData IndepotForm)

{

//得到入库单明细

DataTable tbl=IndepotForm.Tables["InDepotFormDetail"];

try

{

//对于入库单明细中的每个人才，都要修改原有人才的库存数量ProductEntityDAO ped=new ProductEntityDAO();

for(int i=0;i

{

//得到入库单明细的一个人才信息DataRow formdetail=tbl.Rows[i];

string productID=formdetail["ProductID"].ToString();

decimal inCount=(decimal)formdetail["InCount"];

//找到需要修改库存数量的人才

EntityData product=ped.FindByPrimaryKey(productID);

DataRow productRow=product.GetRecord("Product");

//修改人才库存数量

productRow["CurrentCount"]=(decimal)productRow["CurrentCount"]+inCount;

ped.UpdateEntity(product);

}

ped.Dispose();

//保存入库单

InDepotFormEntityDAO inDepotForm=new InDepotFormEntityDAO();

inDepotForm.InsertEntity(IndepotForm);

IndepotForm.Dispose();

//如果成功，结束事务

ContextUtil.SetComplete();

}

catch(Exception ee)

{

//否则，回滚事务

ContextUtil.SetAbort();

业务服务的提供

现在，整个系统的功能部分已经完成了，我们需要将这些功能组装成系统的各个模块，以便客户端的调用。

在前面的开发过程中，我们实际上还没有对系统进行明确的功能模块划分，在这里，我们才开始所谓的模块划分。在所有客户端对系统的调用中，基本上都是调用这个部分的功能，而不会直接调用前面几个部分的内容，这样使系统达到良好的封装性。

这是一个很好的软件开发的方式。采用这种做法，我们可以将前面的内容封装成一个个的组件，在这里，可以根据需要很方便的利用前面的组件进行功能的重新组合，也方便系统的修改和升级，为软件开发的组件化奠定基础。

在本系统中，业务服务位于BusinessFacade目录，在这里，我们将系统分成两个模块：人才资料的维护和仓库事务管理，模块功能调用接口分别封装在ProductManagement和WharehouseManagement类中。这两个类的代码很简单，主要是封装前面几层内容的功能。例如，WharehouseManagement类封装了入库的操作供客户端掉用，他的代码一目了然，如下：

WEB层的设计

1、 WEB层的主要功能是同客户交户，这一层向用户提供服务，主要功能是提供HTML界面，接受用户的输入，调用业务功能等，完成用户的需求。在这个层次里面没有业务逻辑的处理，而只是调用业务层面提供的服务。下面看看一个入库操作的例子。

在这个层次中，我们没有将表单直接写在https://www.360docs.net/doc/ec12055621.html,页面中，而是先把功能写成Web控件，然后再在https://www.360docs.net/doc/ec12055621.html, 页面中引用这些控件。这样做的目的，主要是为了将来的重用性考虑。

开发过程的组织

我们认为，一个好的系统架构，不仅是为了使软件的结构更加清晰，更加有利于修改和重用，而且也应该能够方便团队之间的合作。我们开发的这套系统架构能够很方便团队之间的合作，下面简单介绍一下整个项目的开发过程，供大家参考。当然，这里只是就本项目给大家做一个简介，并不涉及太多的软件工程过程的东西。

1、项目角色的配置。

在这个项目中，因为项目的规模和公司的具体情况，我们没有将角色分得太细，我们安排了如下主要角色：系统分析、界面设计、美工、程序员、数据库设计、测试员。

2、各个阶段参与角色的主要任务

· 在分析阶段，主要是由系统分析员对系统进行需求的分析和基本建模，美工人员则做一些页面的效果图。

· 在设计阶段，系统的模型就比较成熟了，在静态模型（类图）完成后，数据库设计人员可以做数据库设计了。系统分析员可以将业务层面需要提供的服务的接口代码原型写出。当然，这时候，这些类的方法都是空的，会在实现阶段填充。界面设计人员可以做页面了，美工会协助将页面美化。当然，界面设计人员最好是懂一点代码的美工，这样就不需要将这个工作分开了。

· 在实现阶段，主要是程序员实现系统的业务逻辑。因为实体类以及同数据库的交互可以通过我们自己设计的工具很快生成，所以，这个部分的时间会花的很少，主要是处理业务逻辑部分的代码。在这个阶段，界面设计人员也需要将各个功能的页面都完成。当然，这中间会涉及到很多设计修改的工作，这就不是本文论述的范围了。

因为有了业务层面这个层，所以，界面设计人员和处理业务逻辑的程序员的工作，实际上可以分开，这也有利于团队间的分工协作。