系统的分层结构

《系统的分层结构》由会员分享，可在线阅读，更多相关《系统的分层结构（12页珍藏版）》请在金锄头文库上搜索。

1、第 2 章 系统的分层结构21简述我们在解决一个复杂的问题的时候，通常使用的一个技巧就是分解，把复杂的问 题 分解成为若干个简单的问题，逐步地、分别地解决这几个小问题，最后就把 整个问题解决掉。在设计一个复杂的软件系统的时候，同样的，为了简化问题， 我们也通 常使用的一个技术就是分层，每个层完成自身的功能，最后，所有的 层整合起来构成一个完整的系统。分层是计算机技术中的常用方法，一个典型的例子就是TCP/IP技术的OSI七层 模型。在应用软件开发中，典型的就是N层应用软件模型。N层的应用软件系统, 由于其众多的优点，已经成为典型的软件系统架构，也已经为广大开发人员所熟 知。在一个典型的三层应用

2、软件系统中，应用系统通常被划分成以下三个层次：数据库层、应用服务层和用户界面层。如下图（图 2.1）所示：图 2.1其中，应用服务层集中了系统的业务逻辑的处理，因此，可以说是应用软件系统 中的核心部分。软件系统的健壮性、灵活性、可重用性、可升级性和可维护性， 在很大程度上取决于应用服务层的设计。因此，如何构建一个良好架构的应用服 务层，是应用软件开发者需要着重解决的问题。为了使应用服务层的设计达到最好的效果，我们通常还需要对应用服务层作进一 步 的职能分析和层次细分。很多开发者在构建应用服务层的时候，把数据库操 纵、业务逻辑处理甚至界面显示夹杂在一起，或者，把业务逻辑处理等同于数据 库操纵，

3、等等，这些，都是有缺陷的做法。我们将就在这个方面进行设计时可 采用的方案进行一些探讨。在一个分布式应用系统中，整个系统会部署在不同的物理设备上，如上面所示的 三层体系，用户界面和应用服务器可能在不同的设备上，这就涉及到不同机器之 间的通信问题，也就是层间的通信和交互问题。我们已经有了很多可以用于分布 式远程访问的技术，如CORBA，在Java平台上，我们还有Java RMI、EJB,在 Windows 平台上，从 DCOM 到 COM+，再到.Net 下的 Web Service 和.Ne t Remo ting 等。如何选用合适的远程访问技术，也是我们在系统框架中需要考虑的问题。 6 为了使

4、讨论更具有针对性，本文也会讨论一些比较流行的系统架构，例如 J2EE 架构，以及JDO,然后，我们会讨论Websharp在这个方面的一些设计理念。22设计的原则和评判标准同软件工程的原则一样，应用服务层的设计，必须遵循的最重要的原则就是高内 聚和低耦合7。 软件分层的本来目的，就是提高软件的可维护性和可重用性，而 高内聚和低耦合正是达成这一目标必须遵循的原则。尽量降低系统各个部分之间 的耦合度，是应用服务层设计中需要重点考虑的问题。内聚和耦合，包含了横向和纵向的关系。功能内聚和数据耦合，是我们需要达成 的目标。横向的内聚和耦合，通常体现在系统的各个模块、类之间的关系，而纵 向的耦合，体现在系统

5、的各个层次之间的关系。系统的框架，通常包含了一系列规范、约定和支撑类库、服务。对于如何判断一个软件的系统框架的优劣，笔者认为，可以从以下几个方面来评 判：系统的内聚和耦合度这是保证一个系统的架构是否符合软件工程原则的首要标准。层次的清晰和简洁性系统每个部分完成功能和目标必须是明确的，同样的功能，应该只在一个地方实 现。如果某个功能可以在系统不同的地方实现，那么，将会给后来的开发和维护 带来问题。系统应该简单明了，过于复杂的系统架构，会带来不必要的成本和维护难度。在 尽可能的情况下，一个部分应该完成一个单独并且完整的功能。易于实现性如果系统架构的实现非常困难，甚至超出团队现有的技术能力，那么，团

6、队不得 不花很多的精力用于架构的开发，这对于整个项目来说，可能会得不偿失。简单 就是美。可升级和可扩充性一个系统框架，受设计时技术条件的限制，或者设计者本人对系统认识的局限， 可能不会考虑到今后所有的变化。但是，系统必须为将来可能的变化做好准备， 能够在今后，在目前已有的基础上进行演进，但不会影响原有的应用。接口技术， 是在这个方面普遍应用的技巧。是否有利于团队合作开发一个好的系统架构，不仅仅只是从技术的角度来看，而且，它还应该适用于团队 开发模型，可以方便一个开发团队中各个不同角色的互相协作。例如，将 Web 页面和业务逻辑组件分开，可是使页面设计人员和程序员的工作分开来同步进行 而不会互相

7、影响。性能性能对于软件系统来说是很重要的，但是，有的时候，为了能让系统得到更大的 灵活性，可能不得不在性能和其他方面取得平衡。另外一个方面，由于硬件技术 的飞速发展和价格的下降，性能的问题往往可以通过使用使用更好的硬件来获得 提升。23应用服务层的内容应用服务层，通常也被称为业务逻辑层，因为这一层，是应用软件系统业务逻辑 处理集中的部分。然而，我将这一层称为应用服务层，而不称业务逻辑层，因为， 这一层需要处理的不仅仅是业务逻辑，还包含了其他方面的内容。从完整的角度来说，应用服务层需要处理以下内容：数据的表示方式数据，是软件处理的对象。从某种程度上来说，软件，就是数据结构加算法 的说法，是有一定

8、意义的。在面向对象的系统中，数据是用类来表示的，代表了 现实世界实体对象在软件系统中的抽象。考虑所谓的 MVC 模式，这个部分的类属 于 M-实体类的范畴。由于应用软件通常会使用数据库，数据库中的数据，可以 看成是对象的持久化保存。由于数据库一般是关系型的，因此，这个部分，还需 要考虑类（对象）同关系型数据的映射，即通常所说的 O-R MAP 问题。数据的存取方式如同上述所说，软件系统处理的实体对象数据需要持久化保存数据库中，因此， 我们必须处理系统同数据库的交互，以及数据的存取和转换方式的问题。业务逻辑的组织方式在面向对象的系统中，业务逻辑表现为对象之间的交互。有了上述的实体对象， 以 及对

9、象的保存策略，就可以将这些对象组合起来，编写我们的业务逻辑处理 程序。在业务逻辑的处理中，必须保证处理的正确性和完整性，这将会涉及到事 务处理。 通常，我们也会把业务逻辑封装成组件的形式，以得到最大的可重用 性。业务服务的提供方式 在我们完成系统的功能后，如何向客户提供服务，是我们需要考虑的问题。这里 的客户，不仅仅是指软件的使用者，也包括调用的界面、其他程序等。例如，在 一个基于Web的ASP.Net或JSP系统中，业务逻辑功能的客户便是这些ASP.Net 页面或 JSP 页面。业务逻辑组件应该通过什么方式，直接的，或间接的，向这些 客户提供服务,是这一层需要完成的任务。层的部署和层间交互对

10、于一个多层的应用软件系统来说，尤其是大型的应用软件系统，通常需要把不 同的部分部署在不同的逻辑或物理设备上。特别是一些基于Web的应用软件系 统，其部署工作将涉及到Web服务器、组件服务器、数据库服务器等不同的服务 设备。在进行应用软件架构的设计的时候，必须考虑各种不同的部署方案。当系 统需要进行分布式访问的时候，如何统一和简化分布式系统的开发，便成了系统 框架需要考虑的内容。综上所述，一个完整的基于Web的应用软件系统，其架构可以用图2.2来表示 （Websharp 的应用软件系统架构）：图 2.2对于以上各个方面来说，每个问题都可以有很多种策略和方案，但是，在一个系 统 中，应该尽可能的统

11、一这些策略和方案。也就是说，在一个系统，或者一个 项目中，应该统一每个解决每个问题所采用的方法。软件的开发方法是灵活的， 可以用不 同的方法解决相同的问题，这会诱使开发人员采用他们认为能够表现 自己的方法，但是，从整个系统来看，这将会是灾难性的。我们应该尽可能统一， 就是，采用统 一的数据表示方式、统一的数据存取方式、统一的业务逻辑处理 方式等。下面，将就这些部分的设计策略和可用方案进行一些比较详细的论述。24数据实体的表示应用软件系统，从本质上来说，是计算机对现实世界的模拟。现实世界中的实体 对象，在软件系统中，表现为需要处理的数据。在面向对象的系统中，这是通过 “类和”对象来表示的。参考著

12、名的“MVC”模式类可以分成实体类（M）、控制类（C）、和边界类（V），分别代表了实体对象、控制和界面显示。系统中需要处理的数据，在面 向对象的系统中，属于实体类部分。在考虑数据实体层的设计策略的时候，需要把握以下要点： 一致的数据表示方式。在一个系统中，数据的表示方式必须尽可能统一，同时, 在处理单个数据和多个数据的时候，处理方式尽可能一致。因为数据通常是需要存储到数据库中，因此，良好的映射方法是必需的。处理好对象的粒度，即所谓的粗粒度对象、细粒度对象。一般例子考虑一个现实的例子，一个仓库中的产品(Produc t),在系统中可以使用如下定义：public class Productpubl

13、ic st ring Name; /名称public decimal Price;/价格public int Cou nt;/数量可以按照如下方法使用Product类：Produc t p二new Produc t();/处理 Product这是一个包含了三个属性的 Product 类的定义。为了便于说明，在这里，我们尽量将问题简化了。又例如，一张入库单可以使用如下定义：public class Formpublic st ring ID; /入库单编号public Da teTime AddTime; /入库时间public FormDe tail FormDe tails; /入库单明细p

14、ublic class FormDetailpublic Produc t InProduc t; /入库产品public int Coun t; /入库数量对于处理单个对象，通常采用上述的方法，但是，当我们需要处理相同类的一组 对象，也就是处理一个对象集合的时候，就会有一些小小的麻烦。如前所述，我们希望在处理单个对象和对象集合的时候，处理的方式尽量统一， 这对于软件开发的意义是很大的。常用的处理对象集合的方法有：数组表示的方法例如，上面的例子中当一张入库单包含多条入库单明细的时候采用的方法。为了 灵活性，也可以使用容器来，如Java中的Vector或C#的ArrayList(C#)。只是,

15、在处理对象的时候，需要一个类型转换的操作。这个问题，在支持泛型的语言中 不会存在，如使用C+的标准库的容器类。 ObjectCollection 方法。这个方法同上面的方法类似，不同之处在于，为每个实体类设计一个 Collection 类。例如，可以为 FormDetail 设计一个 FormDetailsCollection 类(C#)：public class FormDetailsCollection: ArrayListpublic void Add(FormDetail detail)base.Add(de tail);public new FormDetail thisint nIndex数据集的表示方法。采用这种方法，通常是直接把从数据库查询中获取的数据集(Recordse t)作为数 据处理对象。这种方法在 ASP 应用程序中是非常常见的做法。这种做法简单，初 学者很容易掌握，但是他不是一种面向对象的方法，弊病也很多。EJB 的方法在J2EE体系中，对实体对象的处理的典型方法是Entity Bean。J2EE中使用 Entity Bean来表示数据，以及圭寸装数据的持久化储存(同数据库的交互)。由 于Entit yBean比较消耗资源，而且采用的是远程调用的方