系统的层次划分2

在实际的应用中，定义了这样一个Schdule抽象类后，要获取一个实体对象，因为Schdule类是抽象的，所以你不可以直接使用new操作来初始化Schdule对象，应当通过如下方式取得：

Schdule schdule = EntityManager.CreateObject(typeof(Schdule)) as Schdule;

EntityManager会即时编译出一个Schdule的实现类，并且返回一个对象。

在这种方式下，实体类同数据库表的映射是通过Attribute来实现的。

可以使用另外一种方法来表示一个实体类。在这种方式下，需要编写一个XML映射文件，然后，可以使用如下方式取得一个实体对象：

EntityData schdule =EntityManager.GetEntityData("Schdule");

然后，可以通过如下方式来访问这个对象的属性：

string Title = schdule["Title"]

可以看到，这种方式同传统的方式有点不同。在这种方式下，数据的表现形式只有一个，那就是EntityData。其好处是明显的，不用为每个实体都单独编写一个类，能够大大减少代码的编写量。其缺点也很明显，那就是不能利用编译器类型检测的功能，如果在调用对象的属性的时候，写错了属性的名称，就可能出错，这需要更加仔细的测试工作。但是，这个问题可以通过工具生成代码来解决。 　　

5．数据的存取方式

数据存取的目的，是持久化保存对象，以备后来的使用，如查询、修改、统计分析等。存取的对象，可以是数据库、普通文件、XML甚至其他任何方式，只要保证数据能够长久保存，并且，不会受断电、系统重起等因素的影响。在这个部分，最理想的状况，自然是能够支持除了数据库以外的各种类型的存取方式，或者，至少留有接口，能够比较方便的扩充。

因为数据库是最常用，也是最有效的数据存储方法，因此，支持数据库存储是最首先必须支持的。在不同的平台下，有不同的数据库访问的手段。例如，在Java平台下，有JDBC，在Windows平台下，可以使用ADO、ADO.Net等。但是，这些手段还比较接近底层，在实际操纵数据库的时候，需要编写大量的代码，并且，我们还需要通过手工的方式来完成将程序中的面向对象的数据存储到关系型数据库的工作。这么做，自然编程的效率不高，并且非常容易出错。但是，不可否认，这也是一种可以选用的方式。

从另外一个方面来看，由于我们前面已经解决了数据的映射问题，因此，在数据的存取方面是非常有规律的，我们完全可以让这个工作通过框架来执行。这样，我们一方面可以简化很多同数据库交互方面的代码编写工作量，能够减少出现Bug的几率，另一方面，由于框架封装了不同数据库之间的差异，使得我们在编写程序的时候，不用考虑不同数据库之间的差异，而将这个工作交给框架去做，实现软件的后台数据库无关性。

在这个部分，以下两个部分的类会显得特别重要：

　　◆对象--关系映射的分析类，能够通过既定的方案完成对象--关系的映射，确定数据存取方案

　　◆数据库操纵类：根据映射关系，将数据准确的存储到数据库中，并且封装不同数据库之间的差异。

　　这个部分的操作过程，可以用图(图2.3)大概的表示如下：

图2.3

　　在J2EE中，这个部分比较典型的就是EntityBean中的CMP。由于在BMP中，同数据库的交互部分需要通过手工编写代码的方式来实现，因此，很难享受到容器带来的便利，只是由于EJB2.0以前的标准，CMP的功能，包括映射能力、实体关系模式等方面的功能比较弱，所以，在很多时候，我们不得不使用BMP。现在，EJB2.0，在这个方面的功能已经非常强大了，我们完全可以享受容器带来的便利，而将大部分精力放在实现更加复杂的业务逻辑方面了。

在JDO中，您同样可以通过PersistenceManager来实现同样的目标，例如，您想把一个Customer对象保存到数据库中，可以采用类似于下面的代码：

 

Schdule schdule=new Schdule(……);

PersistenceManager PM=PMFactory.initialize(……);

Pm.persist(schdule);

代码同样非常简明和直观，没有一大堆数据库操纵的代码，也不容易发生差错。

Websharp的方案

同JDO类似，Websharp定义了PersistenceManager接口，这个接口的定义在后面的章节中会给出，这里，我们先看看其使用方式。

当我们有了某个实体对象后，需要保存到数据库中的时候，我们可以使用下面的代码来实现：

         public bool AddSchdule(Schdule schdule)

         {

              PersistenceManager pm =

                   PersistenceManagerFactory.Instance().CreatePersistenceManager();

              try

              {

                   pm.PersistNewObject(schdule);

                   return true;

              }

              catch

              {

                   return false;

              }

              finally

              {

                   pm.Close();

              }

         }

在这里，我们不需要关心具体的数据库版本，框架会封装不同数据库之间的差异，保证数据可以正确的存储到不同的数据库中。

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

在Websharp中，通过Transaction接口，提供了基本的事务处理能力。上面的代码，如果需要使用事务处理，则可以修正如下：

         public bool AddSchdule(Schdule schdule)

         {

              if(!CheckSchdule(schdule))

                   return false;

              PersistenceManager pm =

                   PersistenceManagerFactory.Instance().CreatePersistenceManager();

              Transaction trans = pm.CurrentTransaction;

              trans.Begin();

              try

              {

                   pm.PersistNewObject(schdule);

                   trans.Commit();

                   return true;

              }

              catch

              {

                   trans.Rollback();

                   return false;

              }

              finally

              {

                   pm.Close();

              }

         }

关于事务处理的Transaction接口的更多内容，在后面的章节中会详细说明。

6．业务逻辑的处理

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

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

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

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

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

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

　　在J2EE中，容器提供了事务处理的能力。在.Net平台上，事务处理是通过Windows COM+服务来提供的。在Websharp中，如上面所讲，通过Transaction接口，提供了基本的事务处理能力，能够满足大部分事务处理的要求。当Websharp提供的事务处理能力不能满足需求的时候，可以使用EnterpriseService。

　　下面是一个简单的例子：

     public bool AddSchdule(Schdule schdule,string[] otherPeoples)

     {

         if(!CheckSchdule(schdule))

              return false;

         PersistenceManager pm =

              PersistenceManagerFactory.Instance().CreatePersistenceManager();

         Transaction trans = pm.CurrentTransaction;

         trans.Begin();

         try

         {

              pm.PersistNewObject(schdule);

              foreach(string otherPeople in otherPeoples)

              {

                   Schdule s = EntityManager.CreateObject(typeof(Schdule)) as Schdule;

                   s.GUID = Guid.NewGuid().ToString();

                   s.UserID = otherPeople;

                   s.StartTime = schdule.StartTime;

                   s.EndTime = schdule.StartTime;

                   s.Title = schdule.Title;

                   s.Description = schdule.Description;

                   s.RemidTime = schdule.RemidTime;

                   s.AddTime = DateTime.Now;

                   s.Status = 0;

                   pm.PersistNewObject(s);

              }

                   trans.Commit();

                   return true;

         }

         catch

         {

              trans.Rollback();

              return false;

         }

         finally

         {

              pm.Close();

         }

      }

在业务逻辑这一层，另外一个需要关注的问题是所谓的AOP。关于AOP的内容，我们会在下面的章节中再讨论。

7．业务服务的提供

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

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

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

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

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

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

8．层的部署和层间交互

       对于一个多层的应用软件系统来说，尤其是大型的应用软件系统，通常需要把不同的部分部署在不同的逻辑或物理设备上。特别是一些基于Web的应用软件系统，其部署工作将涉及到Web服务器、组件服务器、数据库服务器等不同的服务设备。在进行应用软件架构的设计的时候，必须考虑各种不同的部署方案。

已经有了很多可以用于远程访问的服务，如此多的实现技术，带来的很大的灵活性，但同时也带来了文题，其中一个就是，有多少种服务端技术，就得有多少种相应的客户端访问技术。甚至，在某些分布式应用系统中，应用逻辑使用不同的技术开发，存在于不同的机器上，有的存在于客户机本机，有的使用.Net Remoting开发，存在于局域网内，有的使用因特网上的Web Service，有的时候，我们希望相同的业务逻辑能够支持不同的客户端。

在这种情况下，我们需要一个一致的服务访问编程模型，以统合不同的服务访问模式，简化系统的开发和部署。Websharp中的Service Locator提供了这样一种能力，开发人员只需要定义服务访问接口，就可以使用一致的方式透明的访问这些服务，而不用理会这些服务之间的不同点。框架会自动生成访问远程服务需要的代理。

使用WSL，你可以使用类似于如下的代码来访问远程服务，而不用关心远程服务的种类：

     public interface ISecuritySystem

     {

         bool Login(string userID,string password);

         void Logout();

         bool IsLogin();

         Suser CurrentUser();

     }

     ……

     //在需要调用服务的客户端：

     ISecuritySystem ss = ServiceLocator.FindService(

                   "SecurityService",typeof(ISecuritySystem)) as ISecuritySystem;

关于WSL的更多内容，在后面会更加详细的讨论。

9．剪裁和取舍

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

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

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

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

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

10．题外话

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

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

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

下面的章节，我们将详细讨论以上所描述的内容的具体实现策略和方法。
版权所有：UML软件工程组织