企业应用架构研究与分析（一）

  这个文章发的比较早，写得很浮！源自自己的年轻和浮躁。文章里有相当（整幅）的篇幅（第三部分——架构回顾于发展）来自网上（记得是matrix.com.cn）。本来想删除此文，后终放弃——留此文以戒身，以戒心浮气躁，提醒自己：未知恒大于以知。

一、引言

面向对象开发思想作为当前开发主流思想，其发展已经相当成熟。在此之上，不仅仅发展出诸如AOP和SOP等具有变革意思的开发技术,，更重要的是融合了多种技术而形成了一整套的开发体系——架构。

   架构从它诞生开始，就深刻影响了全世界的开发人员，不仅仅如此它还带来了开发过程和开发方式的变革。“架构为骨架，设计模式是血肉”一语道出了架构在当今软件开发过程中的重要性。“架构为先”的开发理念极大的提高了开发人员的工作效率。

 

二、面向对象与架构

面向对象与框架

总体而言，系统的开发方式有三种，如下：

1. 结构化设计（自顶向下）——没有提供适当的方法解决并发性问题。

2. 数据驱动设计——广泛应用于信息管理系统，它关注系统的输入输出。

3. 面向对象设计——适应复杂开发并具有良好复用性。

面向对象作为当前程序设计的主流技术，其本质：抽象、封装、多态、继承。第一要着是抽象，而抽象具有是不确定的，具有不同的粗粒度（根据不同的粗粒度可以排列成为一种层次）。在此之上面向对象设计，则是一种工程学方法，在Robert Martin于1995年出版的那本著名的Designing Object-Oriented C++ Application,在回答“什么是面向对象设计”时，Uncle Bob这样写道：面向对象设计的目的是管理程序中各部分之间的依赖关系。最终开发目标就是降低耦合度，实现复用。

软件复用的发展方式——框架：程序主体反主为客，并让辅助组件反客为主，即控制反转。如果一个程序库负担了整个应用程序运行的主干算法，并实现了主动的事件循环、事件处理机制、控制流程，则为框架。

2.1 系统架构的发展

无论是何种开发方式，在技术层面上，建立一个系统从宏观层面来看第一要著是使系统结构化，结构化的途径有三个：分层、管道和过虑、黑板。

1. 分层模式是一种解决大系统的良好的方法。本质上讲分层是抽象的排列。因为大系统复杂性较高，它的抽象层面也相应较多。

2. 管道和过虑通过用来解决数据流的较好方式。

3.黑板则是用来解决不确定性问题的首要途径。当一个问题解决方法缺乏一定模式，而现有的方法集中的每个方法都只能解决问题的一个部分，并各自不相交。黑板可以成为较好的抽象机制。

如上所述，现有企业应用解决方案都是采用分层模式，无论是J2EE还是.Net都应用这种技术。大体的分层如下图：

 

（图1）

 

特别的在J2EE架构中将会被细化，整个系统框架一般的可以分为5层：表示层，用来显示数据，而不做任何的逻辑操作；控制层，负责控制页面间的跳转；逻辑层，逻辑控制；数据层，负责数据访问、更新；支持层，服务器端组件体系。：

?

各个层次间关联如下：

 

以下分层详细讨论：

（一）数据访问层：

数据访问逻辑层采用使用object/relational mapping pattern的Data mapping pattern和active record pattern向上提供数据访问服务。

 

（二）业务层：

业务逻辑层分成三个部分，如下图：

业务层做为系统的最核心部分，其设计决定了系统的工作。一个完整的业务层设计讨论如下：

基础：

1. 业务实体由实体集和实体组成，这些来自数据访问逻辑层。

2. 业务规则定义了对业务实体内部关系，以及业务实体间的关系。

2.1.业务实体内部关系：（除非只有一个规则，否则）可以采用职责链模式。（这样可以避免过多的条件判断。）

2.2.业务实体外部关系：

2.2.1 非强制一对多：可以采用职责链模式。（这样可以避免过多的条件判断。）

2.2.2 强制一对多：采用observer观察者模式。

2.2.3 多对一：可以采用mediator中介者模式。

3. 业务外观把业务实体和业务规则统一起来。

中级：

1. 考虑一个业务规则，其有严格的限制，联系到多个业务对象，同时其关系成网状，例如：一个实体的方法实现必须满足多个实体的状态值，大量的条件判断不可避免。当系统复杂性提高时，网状的关系将不可避免。此时采用以上简单的方法不能满足要求。这时采用扩展有限状态机来实现将可以解决问题。

2. 业务外观层联系实体和规则，当业务的流程性很强时可以采用工作流技术。同时无论是否采用工作流技术，但系统复杂性提高时，应该采用扩展有限状态机来做控制系统。

高级：

1.业务规则和业务外观的外在本质上是一个控制系统。业务规则实现状态的转换，而业务外观委派状态的行为。在业务规则层采用传统方法设计，将不可避免得造成如下之一的情况：1. 控制器庞大而条件判断过多； 2. 产生多个控制系统；3. 多态后系统控制系统之间继续关联关系复杂。造成控制系统维护的困难性提高。 而解决方案就是： 有限状态机。作为一个严格的数学模型，其在状态转换的控制上有明显的优势。

2.业务逻辑的内在本质上只是一个抽象——解决计算方法、约束条件、转换状态三个问题的控制系统的抽象

（三）表现层：

基础：

表现层作为系统用户界面层，有两个工作：1.界面转换控制；2.用户交互数据收集及其完整性与有效性验证。

1. 界面的转换控制： 当系统的转换复杂化后，对转换的控制变的难以接受，系统将出现多个控制器，对系统的行为变的不可把握。因此在这一层可以采用扩展有限状态机来作为控制系统，这样可以保证系统的行为在可控制范围内，同时可以实现分布式协调控制。

2. 用户交互数据收集及其完整性与有效性验证： 用户界面另一个重要工作。对其的验证包括：1. 对数据的有效性如格式，系统可接受范围检查；2. 数据收集的完整性，例如：1.一些数据用户必填；2. 当用户选择某个选项后，另一些数据成为必填。同时一个系统的界面将是多而复杂，在每个界面中实现将变的复杂而困难，因此必须通知统一的交互数据控制器＋XML配置文件进行控制。

高级：

表现层为一个交互应用系统，要解决的最大问题保持内核独立于用户接口，解决方法有三种：MVC和PAC。

1. MVC应用较广泛。本质是变更传播机制确保用户接口和模型间的一致性。

2. PAC（Presentation-Abstaction-Control）应用较少，但是它解决了MVC没有解决的问题——怎样有效组织功能内核的不同部分和用户接口间的通信。因而这个模式尤其适用于由几个不同自给子系统组成的系统。本质是利用agent抽象层。

现在，基本架构的已经从传统的三层模式发展成N层模式，基础数据来源也不限于数据库，相当的来源于XML文件。典型的N层模式框架如在前文展示的J2EE。

同时，在架构的各个层次，如前文讨论，包含了多种技术，有共同的技术也有不同的技术。从整体上，我们可以进行如下分类：

1.Core技术。提供核心服务和运行环境。采用组件配置模式和接口模式。提供缓存服务、事务服务、代理服务、工厂服务。

2.Name技术。提供注册、运行入口和查询接口。

3.Auth技术。提供验证服务、注册服务、验证加密服务和授权码服务。

4.Service技术。提供应用服务。提供运行入口。实现事务服务。载入通讯服务接口。载入同步和并发接口和服务。

5.ORM技术。提供统一的持久化服务。提供统一的CUID接口。

6.UI Form技术。提供界面载入服务。提供装载Service服务接口。使用扩展有限状态机控制界面间转换。

7.Data Rule技术。提供交互数据收集的完整性和有效性验证。

8.Community技术。提供通讯服务。

9.Concurrency技术。提供同步和并发接口和服务。

10.Event Process技术。提供事件处理模式接口。完成多路分解工作。

11.Biz Rule技术。使用扩展有限状态机控制业务规则。

12. Workflow技术。提供工作流管理服务。可以采用使用扩展有限状态机控制。

 

三、架构回顾与发展

（一）传统二层架构C/S

二层架构带来的麻烦很多。

首先是UI层很难由美工和系统设计师来总体设计，由于即使是Delphi之类的可视化开发工具，界面问题还是要程序员自己调整。解决这个问题可以走两条路：用自己的皮肤系统和美工本来就会IDE。

其次是服务层的标准缺少，虽然Corba之类早已出现，但是昂贵的费用和实施的难度太大了。事实上这样的服务层确实有象BEA的Tuxedo，IBM的CICS等，但伸缩性小，使用范围小，不算是老少咸宜。

最后是数据层一般是直接存取数据库，高级一点的是通用性强一点，能多访问几个数据库。但远没有到对象持久化这种程度。

---

（二）传统三层架构B/S

J2EE架构的推出带来了很大的进步，先前推出的PHP、ASP等嵌入式脚本语言只限于一种模板脚本语言而已，真正的架构还是从J2EE开始起的。

早期J2EE还未成熟，这张图应该是J2EE1.2以后的，至少是EJB2.0以后的。

在UI层与其他脚本嵌入语言类似，模板+脚本，仍然没有较好的Action功能，这直到Struts之类的出现才开始改观。

SeesionBean的出现加速了服务层的建立，让业务逻辑真正可以独立出现，尽管现实没有这么理想。

Entity Bean的出现，特别是CMP的出现，建立了对象持久层，数据库再也不需要了解细节了，甚至对象数据存在哪里都没人想知道了，虽然有这样那样的困难和问题。

---

（三）现代多层架构

多层架构是从开源开始的。

Struts是著名的MVC2，尽管现在看来问题还是不少，但是不可否认，它的功劳是显著的。

AspectJ带来了AOP，让开发换个思路。

Spring让这些看上去很简单，重新发掘Bean的力量。

WebWork、JSTL、Tapestry、JSF、PIO、Hibernate、Castor等等一系列的开源计划层出不穷，我可以列到你开始呕吐为止。

有很多显著的特点：

注重UI层的简化开发，强化模板引擎和组件开发，使Action或Lisnter成为标准配备。

服务层强调弱耦合，可以与多个轮子一起工作，方便更换合适的框架，甚至考虑兼容传统系统。

对象持久大行其道，都是针对EJB的软肋去的，但3.0的发布会弥补EJB的问题。

各大厂商争相抢夺市场，工具和服务器和版本飞涨，跳得比计价器还快。

XML大行其道，已经成为标准格式，至少是配置文件和转换模板的标准。

（四）现代架构简介

View 展示层。显示内容、接受用户人工信息。

Template Engine 模板引擎层。使用模板的方式产生最终View展示层的内容。

Action或Listener 动作或监视层。接受用户人工动作、根据动作反馈。

Control 控制UI层。控制UI的动作反馈、页面流程。

Service 服务层。除业务逻辑以外的系统逻辑、访问域逻辑的接口、转发访问域逻辑的请求。

Domain Logic 域逻辑层。业务逻辑、与传统遗留系统的业务逻辑接口。

Domain Model 域模型层。业务模型，与业务有关的对象模型树，包括对象属性和之间的关系。

XML Model。用XML定义的域模型。鉴于XML的重要性，单独列出。

Object Model。用Object对象来定义的域模型。

Object Persistent 对象持久层。将域模型对象持久化。

Database System 数据库系统。关系型或对象型数据库系统，代表了存储系统。

（五）应用级架构

可能应该称为实用架构，因为以下这些架构与现代架构不冲突，是建立在现代架构基础上的应用级架构。

光有现代架构当然对开发来说并没有省心，反而是更增加沟通和培训成本，因此应用级架构，或可称为中间件，非常重要。

应用级架构是用来解决各种业务问题的高层次架构。

Workflow 工作流。解决一切依赖流程的业务系统中的流程部分的问题。工作流只管流程。

E-Form 电子表单。解决一切业务系统中需要频繁变动界面。包括电子表单设计器和编译器。

Protal 门户。解决多个业务系统的高级集成。多业务系统不仅是展示层上的集成，更深入到互动地集成，将可能产生相互影响。

Data Exchange 数据交换。数据传输和格式转换。解决多个业务系统的数据交换问题。

Message 消息中间件。解决异步消息传输问题。

Instance Message 即时消息。解决即时沟通交流问题，并且允许与业务系统互动。

Real-Time 实时系统。对时间和高可靠性的要求。

Embedded 嵌入式系统。开发各种其它设备上的应用系统。