为了封装不同数据库的操作，统一的数据库访问接口是必须的。关于编写通用数据库访问类的内容，可以参见拙作：《 使用设计模式构建通用数据库访问类》。

在这个部分，另外需要注意的是，为了保证数据存储的完整性，应当考虑事务处理的功能。J2EE、JDO和Websharp都支持在数据存储的时候使用事务处理。

业务逻辑的处理

有了上面的工作，我们就可以把这些对象组合起来，编写我们的业务逻辑。在面向对象的系统中，业务逻辑表现为对象之间的交互。在一些简单的系统中，没有复杂的业务逻辑，只是一些数据的维护工作，那么，有了上面两个部分的工作，我们实际上可能已经忘成了大部分的工作。

在这个部分，由于不同系统之间业务逻辑千差万别，基本上没有办法提供统一的模式。但是，应当注意的是，在同一个系统中，采用基本一致的策略是非常必要的，这有助于消除项目内部的不一致性，使项目更加可控。甚至于，这些策略可以扩展成公司部分、甚至所有项目的策略。

值得指出的是，很多人在这个部分操纵数据库，把业务逻辑处理等同于数据库操作，这是不可取的。在业务逻辑处理中，处理的应该是对象，而不是直接同数据库打交道，这样，才能获得更好的系统结构。

在业务逻辑处理部分，由框架提供一些支撑的服务是非常必要的。这其中，最重要的一点就是事务的处理。业务逻辑的处理过程，会涉及到多个对象之间的交互，以及多次同数据库的交互。为了保证处理过程的完整性，必须使用事务处理的方法。框架必须支持事务处理。

事务处理的功能，基本上有两种选择：使用基于数据库连接的事务、使用外部事物处理服务。

使用基于数据库连接的事务，事务处理的性能相对比较高，但是，当系统涉及到多个数据库之间的交互时，基于数据库连接的事务便无能为力了。而使用专用的事务处理服务，能够适应更多的情况，并且，有测试表明，随着数据处理量的上升，两者之间的性能差异会逐渐减小。

在J2EE中，容器提供了事务处理的能力。在.Net平台上，事务处理是通过Windows COM+服务来提供的。在Websharp中，对COM+服务做了一个简单的封装。同时，也能够使用基于数据库连接的事务。

下面是一个简单的例子，表示了一张入库单入库的过程，在这个过程中，需要修改入库单上每种产品的现有库存量：

public void StoreIntoWarehouse(EntityData insertForm)

{

insertForm.SetCurrentTable("FormDetail");

TransactionManager transManager=new TransactionManager();

ProductEntityDAO productDAO=new ProductEntityDAO(true);

FormEntityDAO formDAO=new FormEntityDAO(true);

try

{

if(insertForm.CurrentTable.Rows.Count>0)

do

{

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

decimal inCount=insertForm.GetDecimal("InCount");

EntityData product=productDAO.FindByPrimaryKey(productID);

product["CurrentCount"]=product.GetDecimal("CurrentCount")+inCount;

transManager.AddMethod(

new TransactionManagedFunction(productDAO.UpdateEntity),product);

}while(insertForm.Next());

transManager.AddMethod(

new TransactionManagedFunction(formDAO.InsertEntity),insertForm);

transManager.ExecuteMethods();

}

catch(Exception ee)

{

throw ee;

}

finally

{

productDAO.Dispose();

insertForm.Dispose();

}

}

业务服务的提供

业务外观层（Business Facade）的目的，是隔离系统功能的提供者和使用者，更明确地说，是隔离业务逻辑的软件的用户界面（可以参见Facade设计模式）。这一层没有任何需要处理的逻辑，只是作为后台逻辑处理和前端用户界面的缓冲区，以达到如下目的

◆将用户界面和系统业务逻辑处理分开，这样，当业务逻辑发生变化时，不用修改客户端程序，是一种支持变化的设计方法。

◆使同一个业务逻辑能够处理不同的客户端请求。例如，可以将Facade设计成Web Service，这样，可以同时为传统的WinForm客户端程序、Web程序以及其他外部系统提供服务，而使用相同的应用服务层，同时，也可以实现系统的分布式部署。关于如何做到这一点，可以参见本文所附的Demo程序。

◆作为系统不同模块之间的调用接口。一个系统通常会包含很多模块，这些模块相对独立，又可能互相调用。为了减少各个不同部分之间的耦合度，必须采用一定的设计方法，Facade设计模式就是非常有效的一种，也是业务外观层的基础。

◆有利于项目团队的分工协作。业务外观层作为一个访问接口，将界面设计人员和逻辑设计人员分开，使得系统的开发可以实现纵向的分工，不同的开发人员可以关注自己的领域而不会受到干扰。

业务外观层的代码框架，在系统分析和设计完成后就可以完成，他需要提供的方法，就相当于在界面设计人员和逻辑设计人员之间签订了一个协议，他虽然没有实现任何逻辑，但是，他的引入，能使系统的开发更加有条理，更加简明。套用《设计模式》上的一句话，就是，"任何问题，都可以通过引入一个中间层来得到简化"。

剪裁和取舍

以上四个层次，对于大型的应用软件系统来说，是非常必要的。但是，对于一些小型的应用软件系统，如果完全按照以上的层次来做，可能反而会影响工作效率。因此，针对不同的系统，可以对架构进行一定的剪裁。

数据实体层和实体控制层，是每个应用软件系统所必需的，显然无法裁减。对于业务逻辑层和业务外观层，根据实体情况，可以进行如下裁减：

◆如果系统没有复杂的业务逻辑，而只是一些数据的操作，或者业务逻辑特别少，那么，可以省略业务逻辑层，而将相关的功能移至实体控制层。

◆如果不考虑多种客户端的情况，也不考虑分布式部署的问题，系统的模块又很少，不会产生模块间紧耦合的情况，那么，可以不使用业务外观层，而让用户界面程序直接访问业务功能。

在上面的论述中，对于每个层次，都说明了可以选择的多种方案，每一种方案都有他的优点和缺点，在具体开发的过程中，需要根据具体情况加以取舍。

系统外的话

应用软件系统架构，是软件工程的重要组成部分。设计一个好的框架，其目的很明确，那就是，在目前还没有"银弹"之前，尽最大的可能，提高软件开发的效率和软件质量，把不必要的工作和容易出错的工作，交给框架去处理。

应用服务层，在软件系统中，是一个非常复杂的部分，乍看之下，没有任何规律可行，给人无从下手的感觉。我们的目标，就是尽量化无规律为有规律，把有规律的东西提取出来，形成规范，从而减少今后的开发工作量。其方法，就是对系统进行合理的分层，这样，系统的层次清晰了，每个层次完成的功能就比较单一，就意味着每个层次的都相对更有规律可循，这样，我们就可以把这些有规律的东西交给框架去执行，或者，开发一个辅助工具，来完成这部分的代码编写工作。Websharp就提供了这样一个代码自动生成的工具。这个工具被设计成Visual Studio.Net集成开发环境的插件，在实际开发过程中，能够提供很多便利。这是系统层次清晰带来的另外一个好处。

对于一个软件公司来说，统一的系统框架的意义不仅仅在于软件开发的本身。一个统一的系统框架，也是公司知识管理的重要组成部分。公司如果有一个或有限个数的明确的软件框架，那么，这些框架就可以成为凝结公司开发人员经验、智慧的载体，并且可以在不断的实践中加以充实和完善。由于公司的软件系统的框架比较统一，那么当某个项目更换或增加开发人员的时候，后来的人也能够比较容易接手，这对于公司的开发管理是具有非常重要的意义的。

关于系统框架同知识管理的关系的内容，因为不是本文的重点，限于篇幅的关系，所以不再赘述，会另文加以说明。

结语

应用软件系统的应用服务层是非常复杂的，为了使得系统的结构更加清晰，找出其中规律性的东西，就需要我们对系统做进一步的层次划分。对于每个层次，都可以有多种设计的策略，每一种策略都不可能做到尽善尽美，这就需要我们在实际中加以取舍。

限于本人的认识和水平，文章中所说观点和方法或有不当之处，还请大家能够指教，一起探讨。