一、层次式体系结构概述

软件体系结构贯穿于软件研发的整个生命周期内，具有重要的影响，从以下三方面来进行考察：

利益相关人员之间的交流，包括程序员在内的绝大多数系统的利益相关人员都借助软件体系结构来作为相互沟通的基础系统设计的前期决策可传递的系统级抽象

分层架构大部分会分成表现层（展示层）、中间层（业务层）、数据访问层（持久层）和数据层

二、表现层框架设计

软件层次式体系结构是最通用的架构，也被叫作N 层架构模式。大部分的应用会分成表现层(或称为展示层)、中间层(或称为业务层)、数据访问层(或称为持久层)和数据层。

◆使用XML设计表现层。

UIP 提供了一个扩展的框架，用于简化用户界面与商业逻辑代码的分离的方法，可以用它来写复杂的用户界面导航和工作流处理，并且它能够复用在不同的场景、并可以随着应用的增加而进行扩展

◆使用UIP框架的应用程序把表现层分为了以下几层。

UserInterface Components:这个组件就是原来的表现层，用户看到的和进行交互都是这个组件它负责获取用户的数据并且返回结果。

User Interface Process Components:这个组件用于协调用户界面的各部分，使其配合后台的活动，例如导航和工作流控制，以及状态和视图的管理。用户看不到这一组件，但是这些组件为User Interface Components提供了重要的支持功能。

◆表现层动态生成设计:基于XML 的界面管理技术可实现灵活的界面配置(静态)、界面动态生成和界面定制(动态)。其思路是用XML生成配置文件及界面所需的元数据，按不同需求生成界面元素及软件界面

2.1 MVC模式

(1) 控制器接收用户的请求，并决定应该调用哪个模型来处理；

(2) 模型根据用户请求进行相应的业务逻辑处理，并返回数据；

(3) 控制器调用相应的视图来格式化模型返回的数据，并通过视图呈现给用户。

使用MVC模式来设计表现层，可以有以下优点：

（1）允许多种用户界面的扩展。

（2）易于维护。

（3）易于构建功能强大的用户界面。

（4）增加应用的可拓展性、强壮性、灵活性。

2.2 MVP模式

MVP(Model-View-Presenter)模式提供数据，View负责显示，Controller/Presenter负责逻辑的处理。MVP是从经典的模式MVC演变而来，它们的基本思想有相通的地方：Controller/Presenter负责逻辑的处理，Model提供数据，View负责显示。当然MVP卢亏MVC也有一些显著的区别，MVC模式中元素之间“混乱”的交互主要体现在允许View和Model直接进行“交流”，这在MVP模式中是不允许的。在MVP中View并不直接使用Model,它们之间的通信是通过Presenter(MVC中的Controller)来进行的，所有的交互都发生在Presenter内部，而在MVC中View会直接从Model中读取数据而不是通过Controller。

MVP不仅仅避免了View和Model之间的耦合，还进一步降低了Presenter对View的依赖。Presenter依赖的是一个抽象化的View,即View实现的接口IView,这带来的最直接的好处，就是使定义在Presenter中的UI处理逻辑变得易于测试。由于Presenter对View的依赖行为定义在接口IView中，只需要一个实现了这个接口的View就能对Presenter进行测试。

使用MVP模式来设计表现层，可以有以下的优点：

（1）模型与视图完全分离，可以修改视图而不影响模型。

（2）所有的交互都发生在一个地方 - Presenter内部，因此可以更高效地使用模型。

（3）可以将一个Presenter用于多个视图，而不需要改变Presenter的逻辑。因为视图的变化总是比模型的变化频繁。

（4）如果把逻辑放在Presenter中，就可以脱离用户接口来测试这些逻辑（单元测试）。

2.3 MVVM模式

MVVM模式全称是模型－视图－视图模型(Model-View-ViewModel)，它和MVC、MVP类似，主要目的都是为了实现视招和模型的分离，不同的是MVVM中，View与Model的交互通过ViewModel来实现。

ViewModel是MVVM的核心，它通过DataBinding实现View与Model之间的双向绑定，其内容包括数据状态处理、数据绑定及数据转换。例如，View中某处的状态和Model中某部分数据绑定在一起，这部分数据一旦变更将会反映到View层。而这个机制通过ViewModel来实现。

在MVVM模式下View和Model不能直接通信，两者的通信只能通过ViewModel来实现。ViewModel通常要实现一个观察者，当数据发生变化，ViewModel能够监听到数据的变化，然后通知对应的视图做自动更新；而当用户操作视图，ViewModel也能监听到视图的变化，再通知数据做改动，从而形成数据的双向绑定。这使得MVVM更适用于数据驱动的场景，尤其是数据操作特别频繁的场景。

但也正是由于数据和视图的双向绑定，导致出现问题时不太好定位来源，有可能由数据问题导致、也有可能由业务逻辑中对视图属性的修改导致。

三、中间层架构设计

3.1 业务逻辑层组件设计

业务逻辑层组件分为接口和实现类两个部分。接口用于定义业务逻辑组件，定义业务逻辑组件必须实现的方法是整个系统运行的核心。通常按模块来设计业务逻辑组件，每个模块设计一个业务逻辑组件，并且每个业务逻辑组件以多个数据访问对象（Data Access Object，DAO）组件作为基线，从而实现对外提供系统的业务逻辑服务。

增加业务逻辑组件的接口，是为了提供更好的解耦控制器无须与具体的业务逻辑组件耦合，而是面向接口编程。

3.2 业务逻辑层工作流设计

工作流管理联盟（Workflow Management Coalition，WFMC）将工作流定义为：业务流程的全部或部分自动化，在此过程中，文档、信息或任务按照一定的过程规则流转，实现组织成员间的协调工作已达到业务的整体目标。

工作流参考模型见图其包含6个基本模块，分别是工作流执行服务、工作流引擎、流程定义工具、客户端应用、 调用应用和管理监控工具。

3.3 业务逻辑层实体设计

逻辑层实体提供对业务数据及相关功能（在某些设计中）的状态编程访问。业务逻辑层实体可以使用具有复杂架构的数据构建，这种数据通常来自数据库中的多个相关表。业务逻辑层实体数据可以作为业务过程的部分I/O参数传递。业务逻辑层实体是可序列化的以保持他们的当前状态。

在应用程序中表示业务逻辑层实体的方法有很多(从以数据为中心的模型到更加面向对象的表示法)，如XML、通用DataSet、有类型的DataSet等。

如下左图是业务实体用XML表示，右图所示为用于0rder业务逻辑层实体的通用DataSet 对象。此DataSet 对象具有两个Data Table对象，分别保存订单信息和订单详细信息。每个DataTable 具有一个对应的UniqueConstraint 对象，用于标识表中的主键。此外，该DataSet 还有一个Relation对象，用于将订单详细信息与订单相关联。

3.4 业务逻辑层框架

业务逻辑框架位于系统架构的中间层，是实现系统功能的核心组件。采用容器的形式，便于系统功能的开发、代码重用和管理。在业务容器中，业务逻辑是按照Domain Model-Service-Contro思想来实现的。其中：

业务框架位于系统架构的中间层，是实现系统功能的核心组件。采用容器的形式，便于系统功能的开发、代码重用和管理。下图便是在吸收了S0A思想之后的一个三层体系结构的简图。

业务层采用业务容器的方式存在于整个系统当中采用此方式可以大大降低业务层和相邻各层的耦合表示层代码只需要将业务参数传递给业务容器，而不需要业务层多余的干预。如此一来，可以有效地防止业务层代码渗透到表示层。

在业务容器中，业务逻辑是按照Domain Model-Service-Control 思想来实现的。

（1）Domain Model是仅仅包含业务相关的属性的领域层业务对象。

（2）Service是业务过程实现的组成部分，是应用程序的不同功能单元，通过在这些服务之间定义良好的接口和契约联系起来。

（3）Control服务控制器，是服务之间的纽带，不同服务之间的切换就是通过它来实现的。

四、数据访问层框架设计

4.1 5种数据访问模式

（1）在线访问:会占用一个数据库连接，读取数据，每个数据库操作都会通过这个连接不断地与后台的数据源进行交互。

（2）DataAccess 0bject:是标准J2EE 设计模式之一，开发人员常常用这种模式将底层数据访问操作与高层业务逻辑分离开

（3）Data Transfer 0bject:是经典EJB设计模式之一。DTO本身是这样一组对象或是数据的容器，它需要跨不同的进程或是网络的边界来传输数据。这类对象本身应该不包含具体的业务逻辑，并且通常这些对象内部只能进行一些诸如内部一致性检查和基本验证之类的方法，而且这些方法最好不要

再调用其他的对象行为。

（4）离线数据模式是以数据为中心，数据从数据源获取之后，将按照某种预定义的结构存放在系统中,成为应用的中心。离线，对数据的各种操作独立于各种与后台数据源之间的连接或是事务。

（5）对象/关系映射(0bject/Relation Mapping,O/R Mapping):大多数应用中的数据都是依据关系模型存储在关系型数据库中;而很多应用程序中的数据在开发或是运行时则是以对象的形式组织起来的。那么，对象/关系映射就提供了这样一种工具或是平台，能够帮助将应用程序中的数据转换成关系型数据库中的记录;或是将关系数据库中的记录转换成应用程序中代码便于操作的对象。

4.2 工厂模式在数据数据访问层的应用

这就需要在实际开发过程中将这些数据库访问类再作一次封装。经过这样的封装，不仅可以达到上述的目标，还可以减少操作数据库的步骤，减少代码编写量。工厂设计模式是使用的主要方法。

工厂模式定义一个用于创建对象的接口，让子类决定实例化哪一个类。工厂方法使一个类的实例化延迟到其子类。这里可能会处理对多种数据库的操作，因此，需要首先定义一个操纵数据库的接口DataAccess，然后根据数据库的不同，由类工厂决定实例化哪个类。

◆因为DataAccess 的具体实现类有一些共同的方法，所以先从DataAccess实现一个抽象的AbstractDataAccess类，包含一些公用方法。然后，分别为SQL Server、0racle 和0leDb数据库编写三个数据访问的具体实现类。

◆现在已经完成了所要的功能，下面需要创建一个Factory类，来实现自动数据库切换的管理。这个类很简单，主要的功能就是根据数据库类型，返回适当的数据库操纵类。

4.3 ORM、Hibernate与CMP2.0设计思想

ORM(Object-Relation Mapping) 在关系型数据库和对象之间作一个映射，这样，在具体操纵数据库时，就不需要再去和复杂的 SQL语句打交道，只要像平时操作对象一样操作即可。当开发一个应用程序的时候(不使用OR Mapping), 可能会涉及许多数据访问层的代码，用来从数据库保存、删除和读取对象信息等，然而这些代码写起来总是重复的。一个更好的办法就是引入OR Mapping。 实质上，一个 OR Mapping会生成DAL。 与其自己写DAL代码，不如用OR Mapping, 开发者只需要关心对象就好。

4.4 XML Schema

XML Schema用来描述XML文档合法结构、内容和限制。 XML Schema由XML 1.0 自描述，并且使用了命名空间，有丰富的内嵌数据类型及其强大的数据结构定义功能，充分地改造了并且极大地扩展了 DTDs (传统描述XML文档结构和内容限制的机制)的能力，将逐步替代DTDs, 成为 XML体系中正式的类型语言，同 XML 规范、 Namespace 规范一起成为XML体系的坚实基础。

4.5 事务处理设计

事务是现代数据库理论中的核心概念之一。如果一组处理步骤或者全部发生或者一步也不执行，我们称该组处理步骤为一个事务。当所有的步骤像一个操作一样被完整地执行，我们称该事务被提交。由于其中的一部分或多步执行失败，导致没有步骤被提交，则事务必须回滚(回到最初的系统状态)。事务必须服从 ISO/IEC所制定的ACID原则。 ACID是原子性(Atomicity)、 一致性(Consistency)、 隔离性 (Isolation) 和持久性 (Durability) 的缩写。事务的原子性表示事务执行过程中的任何失败都将导致事务所做的任何修改失效。一致性表示当事务执行失败时，所有被该事务影响的数据都应该恢复到事务执行前的状态。隔离性表示在事务执行过程中对数据的修改，在事务提交之前对其他事务不可见。持久性表示已提交的数据在事务执行失败时，数据的状态都应该正确。

JavaBean中使用JDBC方式进行事务处理:在JDBC 中，打开一个连接对象Connection 时，默认是auto-commit模式，每个SQL语句都被当作一个事务，即每次执行一个语句，都会自动地得到事务确认。为了能将多个SQL语句组合成一个事务，要将auto-commit模式屏蔽掉。在auto-commit 模式屏蔽掉之后，如果不调用commit()方法，SQL语句不会得到事务确认。在最近一次commit()方法调用之后的所有SQL会在方法commit()调用时得到确认。

4.6 连接对象管理设计

对于共享资源，有一个很著名的设计模式——资源池。该模式正是为了解决资源频繁分配、释放所造成的问题。把该模式应用到数据库连接管理领域，就是建立一个数据库连接池，提供一套高效的连接分配、使用策略。

建立连接池的第一步，就是要建立一个静态的连接池。所谓静态，是指池中的连接是在系统初始化时就分配好的，并且不能够随意关闭。Java 中给我们提供了很多容器类，可以方便地用来构建连接池，如Vector、Stack等。在系统初始化时，根据配置创建连接并放置在连接池中，以后所使用的连接都是从该连接池中获取的，这样就可以避免连接随意建立、关闭造成的开销。

有了这个连接池，下面就可以提供一套自定义的分配、释放策略。当客户请求数据库连接时，首先看连接池中是否有未分配出去的连接。如果存在空闲连接则把连接分配给客户，并标记该连接为已分配。若连接池中没有空闲连接，就在已经分配出去的连接中，寻找一个合适的连接给客户，此时该连接在多个客户间复用。

当客户释放数据库连接时，可以根据该连接是否被复用，进行不同的处理。如果连接没有使用者就放入到连接池中，而不是被关闭。

五、数据架构规划与设计

5.1 数据库与类的设计融合

对类和类之间关系的正确识别是数据模型的关键所在。本节将讨论如何发现、识别以及描述类。要想将建模过程缩减为一个简单的、逐步进行的过程是不太可能的。从本质上讲，建模是一项艺术。对一个给定的复杂情况而言，不存在唯一正确的数据模型，然而却存在好的数据模型。一个企业或机构的某个数据模型可能会优于另一个数据模型，但就如何为一个特定的系统建立数据模型，却没有唯一的解决方案。

好模型的目标是将工程项目整个生存期内的花费减至最小，同时也会考虑到随时间的推移系统将可能发生的变化，因而设计时也要考虑能适应这些变化。因此，将目光集中在最大限度地降低开发费用上是一个错误。

5.2 数据库设计与XML设计融合

XML文档分为两类：一类是以数据为中心的文档，这种文档在结构上是规则的，在内容上是同构的，具有较少的混合内容和嵌套层次，人们只关心文档中的数据而并不关心数据元素的存放顺序，这种文档简称为数据文档，它常用来存储和传输 Web 数据。另一类是以文档为中心的文档，这种文档的结构不规则，内容比较零散，具有较多的混合内容，并且元素之间的顺序是有关的，这种文档常用来在网页上发布描述性信息、产品性能介绍和 E-mail信息等。

经提出的XML文档的存储方式有两种:基于文件的存储方式和数据库存储方式。

(1)基于文件的存储方式。基于文件的存储方式是指将XML文档按其原始文本形式存储，主要存储技术包括操作系统文件库、通用文档管理系统和传统数据库的列。这种存储方式需维护某种类型的附加索引，以建立文件之间的层次结构。基于文件的存储方式的特点:无法获取XML文档中的结构化数据;通过附加索引可以定位具有某些关键字的XML文档，一旦关键字不确定，将很难定位;查询时，只能以原始文档的形式返回，即不能获取文档内部信息;文件管理存在容量大、管理难的缺点。

(2)数据库存储方式。数据库在数据管理方面具有管理方便、存储占用空间小、检索速度快、修改效率高和安全性好等优点。一种比较自然的想法是采用数据库对XML文档进行存取和操作，这样可以利用相对成熟的数据库技术处理XML文档内部的数据。数据库存储方式的特点:能够管理结构化和半结构化数据;具有管理和控制整个文档集合本身的能力;可以对文档内部的数据进行操作;具有数据库技术的特性，如多用户、并发控制和一致性约束等;管理方便，易于操作。

六、物联网层次架构设计

从实用角度来看，物联网 (IoT) 囊括连接到 Internet 的任何设备， 其中包括电脑、移动电话、智能表、智能调温器、智能致冷器、联网汽车、植入式心脏监测仪，以及任何其他可以连接到 Internet 并可发送或接收数据的设备。

物联网可以分为三个层次，底层是用来感知数据的感知层，即利用传感器、二维码、RFID等设备随时随地获取物体的信息。第二层是数据传输处理的网络层，即通过各种传感网络与互联网的融合，将对象当前的信息实时准确地传递出去。第三层则是与行业需求结合的应用层，即通过智能计算、云计算等将对象进行智能化控制。

（1）感知层:

感知层用于识别物体、采集信息。感知层包括二维码标签和识读器、 RFID标签和读写器、摄像头、 GPS、 传感器、 M2M 终端、传感器网关等，主要功能是识别对象、采集信息，与人体结构中皮肤和五官的作用类似。感知层解决的是人类世界和物理世界的数据获取问题。

（2）网络层:

网络层用于传递信息和处理信息。网络层包括通信网与互联网的融合网络、网络管理中心、信息中心和智能处理中心等。网络层将感知层获取的信息进行传递和处理，类似于人体结构中的神经中枢和大脑。网络层解决的是传输和预处理感知层所获得数据的问题。

（3）应用层：

应用层实现广泛智能化。应用层是物联网与行业专业技术的深度融合，结合行业需求实现行业智能化，这类似于人们的社会分工。物联网应用层利用经过分析处理的感知数据，为用户提供丰富的特定服务。应用层解决的是信息处理和人机交互的问题。