技术平台研发目标

1           逻辑架构

从C/S/S物理架构角度观察这些逻辑层，业务过程层上的“数据校验逻辑”、“数据权限逻辑”按照即时响应原则是放在客户端的，业务实体是在客户端、服务端之间移动的（变换形式、远程传递、保真重现），数据访问层一定是部署在服务端的。

2           数据传递

在设计分布式应用程序时需要确定如何访问和表示与该应用程序相关联的业务数据。

2.1         目前有几种模式供选择：

l         XML。使用 XML 字符串或 XML 文档对象模型 （DOM） 对象来表示业务实体数据。XML 是一种开放而灵活的数据表示格式，可用于集成各种类型的应用程序。

l         DataSet。DataSet 是缓存在内存中的表，它是从关系数据库或 XML 文档中获得的。数据访问逻辑组件可以使用 DataSet 来表示从数据库中检索到的业务实体数据，您可以在应用程序中使用该 DataSet。

l         有类型的 DataSet。有类型的 DataSet 是从 ADO.NET DataSet 类继承而来的类，它为访问表和 DataSet 中的列提供了具有严格类型的方法、事件和属性。

l         业务实体组件。这是一种自定义类，用于表示各种业务实体类型。您可以定义保存业务实体数据的字段，并定义将此数据向客户端应用程序公开的属性，然后使用在该类中定义的字段来定义方法以封装简单的业务逻辑。此选项并不通过 CRUD 方法实现与基础数据访问逻辑组件的数据传递，而是通过客户端应用程序直接与数据访问逻辑组件进行通信以执行 CRUD 操作。

l         带有 CRUD 行为的业务实体组件。按上述方法定义一个自定义实体类，并实现调用与此业务实体相关联的基础数据访问逻辑组件的 CRUD 方法。

2.2         从C/S/S开发角度提出的要求

l         需要把业务实体数据与WinForm控件绑定在一起；

l         需要对业务实体数据执行排序或搜索操作；

l         应用程序每次处理一组业务实体；

l         是远程部署应用程序；

l         必须均衡考虑非功能性要求：编程方便性（业务开发者）、性能（业务系统），可维护性（业务开发者）、可缩放性（业务系统）；

2.3         采用的主要模式和适用场景

2.3.1       带有 CRUD 行为的业务实体组件

通过在业务实体基类、业务实体集合基类上封装对数据访问层的 CRUD 操作，业务开发人员仅需定义业务实体类、业务实体集合类（可采用第三方的代码生成器，如CodeSmith），并配置与数据库表结构的对映关系，其余的工作都是由技术平台实现，比如如何传递这些业务实体等等。

业务开发人员定义的业务实体类可能是这样的形式：

[Serializable()]

[DataMapperClass("PH_User")]

  public class User : BusinessBase<User>

  {

    [DataMapperField(IsIdentity = true, NeedUpdate = true, ColumnName = "US_ID")]

    private long _id;

    public long Id

    {

      get { return _id; }

    }

 

    [DataMapperField(NeedUpdate = true, ColumnName = "US_Name")]

    private string _userName;

    public string UserName

    {

      get { return _userName; }

      set { _userName = value; }

    }

 

    [DataMapperField(NeedUpdate = true, ColumnName = "US_UserNumber")]

    private string _userNumber;

    [Indexable(IndexModeEnum.IndexModeOnDemand)]

    public string UserNumber

    {

      get { return _userNumber; }

      set { _userNumber = value; }

    }

}

业务开发人员最多在业务实体集合类中定义如何获取业务实体对象集合的select语句，但如何获取数据、如何构建和填充业务实体对象，这些过程都是业务实体集合基类和数据访问层共同完成的任务，业务实体集合基类只需暴露Fetch()接口函数供业务代码调用即可。

业务实体对象的数据提交，对于业务开发人员来说，他是不用写一行代码的，业务实体集合基类和数据访问层根据业务实体类的定义，会自动拼接数据提交语句，并在数据访问层中最终实现数据的持久化，业务实体集合基类只需暴露Save()接口函数供业务代码调用即可。

更深层探究，技术平台在业务实体基类和业务实体集合基类上，除了前面提到的，还需要完成的功能如下：

A.       业务实体的状态属性：是否脏数据、是否新增数据、是否被删除数据、是否允许提交。

B.       业务实体修改过程的快照：结合UI框架，实现N层撤销功能。

C.       业务实体的有效性校验：对属性的写操作进行管理，一旦通不过有效性校验，则UI框架自动提示（比如结合ErrorProvider控件）给用户，业务开发人员仅需在业务实体类上通过基类暴露的AddValidationRule ()接口函数来注册自己的校验规则函数，而一些常规的校验规则函数，比如：必填、最大最小长度、最大最小值、填充格式等等，技术平台应该提供具体的实现。

D.       业务实体的权限校验：结合当前用户的权限，提供属性的可读写校验机制，比如通过业务实体基类暴露的接口函数AddAuthorizationRule()来注册属性的可读写控制策略。

E.       业务实体集合的权限控制：结合当前用户的权限，提供业务实体的可浏览、可编辑、可删除、可新增等属性等等，业务实体基类仅需暴露接口函数AddAuthorizationRule()来供业务开发人员注册这个业务实体的权限控制策略，基于此功能，再与业务组件框架、UI框架结合，实现菜单、按钮等导航控件的权限控制。

F.       业务实体集合的事务控制：结合业务组件的开发，为数据访问层实现数据库事务，提供控制机制。

G.       业务实体集合的并发控制：结合业务组件的开发，为数据访问层实现并发策略，提供控制机制。

H.       业务实体集合的索引机制：为实现对业务实体数据执行高效的排序、搜索、过滤操作而自动构建索引器，并对它们进行管理的机制，业务开发人员仅需调用业务实体集合基类暴露的OrderBy(属性名集合，次序类型)、Locate(属性名集合, 搜索条件, 匹配条件)、Filter（属性名集合, 过滤条件, 匹配条件）等等接口函数，得到自己所需的业务实体子集。

I.       业务实体集合：实现IbindingList接口，为将数据绑定到UI控件提供内置的支持。

J.       带参数条件的业务实体集合：对应与SQL语句的where条件，业务开发人员所定义的业务实体通过带参数的条件，在运行期动态改变参数，下载需要的数据。技术平台需要提供参数基类结合业务实体集合基类实现此功能，而业务开发人员仅需定义参数类即可。

K.       业务实体集合的层次结构：1对N，并可N层嵌套，这样的层次结构，技术平台需管理其数据的CRUD。

L.       公开属性更改的事件：结合UI框架，使得无论数据显示在哪里都可以通过事件刷新界面。

M.       业务实体可序列化。因为业务实体在各个逻辑层和物理层之间进行穿越，对其进行的基本操作CURD将在各个层上以不同的形式被实现，而可序列化保证了高保真穿越的可能性。

N.       业务实体通过运行在客户端“业务过程代理”和服务端的“业务过程门户”两套组件实现在各个逻辑层上的CRUD和穿越各个逻辑层的集中管理；在“业务过程代理”和“业务过程门户”之间，还隐藏着具体的被封装了的分布式协议及其框架，比如WCF等。这样，业务代码的实现将与具体的技术实现无关，提高了业务代码的可移植能力，延长了产品的生命周期，而对于业务开发人员来说，则是彻底的技术透明感，他们仅需针对“业务过程代理”和“业务过程门户”提供的接口进行编程即可，再次降低了技术门槛。

业务实体组件的优点及其适用场景：

A.       代码易读：要访问自定义实体类中的数据，可以使用有类型的方法和属性。

B.       封装：自定义实体可以包含方法以封装简单的业务规则（见前文，由技术平台辅助实现）。这些方法操作缓存实体组件中的业务实体数据，而不是访问数据库中的实时数据。

C.       构建复杂系统的模型：在构建复杂域问题（在不同业务实体之间存在很多交互）的模型时，可以定义自定义实体类，从而将复杂性隐藏在经过很好定义的类接口的后面，比如计算服务等业务场景。

D.       本地化验证：自定义实体类可以在其属性存取器中执行简单的验证测试以检测无效的业务实体数据（见前文，由技术平台辅助实现）。

E.       专用字段：您可以隐藏不希望向调用程序公开的信息。

业务实体组件的缺点及其规避方法：

A.       业务实体集合：要保存多个业务实体，需要设计业务实体集合类（见前文，由技术平台提供基类实现）。

B.       序列化：技术平台通过实现 ISerializable 接口来控制自己的序列化，做到深层序列化。

C.       表示业务实体中的复杂关系和层次结构：见前文，由技术平台提供基类实现。

D.       搜索和排序数据：见前文，由技术平台提供基类实现。

E.       部署：必须在所有物理层部署包含自定义实体的程序集。技术平台针对此特性在部署服务中管理上这些组件，做到维护人员在一个物理位置做升级动作，部署服务将自动升级到已知（注册的）的应用服务器上，客户端实现自动下载和升级；这些过程，业务开发人员不写一行代码。

F.       可扩展性问题：如果修改了数据库架构，则可能需要修改自定义实体类（首次写代码可以依靠第三方的代码生成器，如CodeSmith，但修改的话还是要靠开发人员手工维护代码）并重新部署程序集（由技术平台部署功能模块支撑）。

2.3.2       DataSet

ADO.NET与MIDAS从一定的高度来看，何其相像，他们都是以实用主义为出发点，采用数据包的传递方式、实现在各个逻辑层上的CRUD，以及数据的索引、搜索、过滤等等功能。他们都是并为了实现分布式应用、数据库离线模式等应用场景而诞生的。相对照而言，带有CRUD行为的业务实体，则是不折不扣按照面向对象理论对此重新了演绎，而实现的功能是一致的。这两种模式，适合于不同的业务场景，结合起来使用，将达到相辅相成的效果。

由于应用场景都是一致的，所以对业务实体的要求也是对DataSet的要求，这里就不在累述了。当然上述的功能需求，ADO.NET也已经实现了大部分，其余的则需要技术平台实现了。

和业务实体一样，对于大部分的DataSet，仅有CRUD这些有规则的业务逻辑。那么是否可以在技术平台上完全封装掉这些功能呢，而最终得到的效果是：业务开发人员仅需以面向对象的形式定义select语句、where参数条件，剩下的工作完全由技术平台实现，技术平台在基类上提供标准的CRUD接口：Fetch()、Save()、OrderBy(属性名集合，次序类型)、Locate(属性名集合, 搜索条件, 匹配条件)、Filter（属性名集合, 过滤条件, 匹配条件）等等接口函数，通过事件来与UI数据感知控件进行交互。

更深层探讨，就是需要技术平台完全实现：客户端“业务过程代理”和服务端的“业务过程门户”及其他们之间的被封装了的分布式协议及其框架。

可以说，在这样的开发场景里，除了前文所述业务开发人员需做的工作和UI界面的代码设计外，剩下的，特别是服务层的实现，100%不用开发人员写一行代码。

DataSet主要的缺点是打包数据比较费时。其次，因为需要使用大量的字符串做标识，造成代码编写容易出错，后期维护比较麻烦。这个问题可以采取统一标识命名规则与用语，制定编写规则，从而方便业务开发人员和维护人员采用关键字进行代码检索，从而快速定位嫌疑点。

DataSet的另外一个缺点是缺乏面向对象特性，这是其本质决定的，但从那些希望满眼都应该是对象的OO信徒来说，这就是个严重缺陷了。恩，如此的话不用就是了，但这已不是技术平台的问题了。

3           数据访问层

完全由技术平台实现，并提供接口供业务实体基类、业务实体集合基类、DataSet基类调用（业务过程层和数据访问层之间的衔接也是由技术平台完全实现），对于业务开发人员来说，不用考虑是他们如何运作的。

数据访问层内部需要实现的功能如下：

l         CURD：具体实现的地方。相关内容见上文，此处不再展开。

l         事务：具体实现的地方。由于分布式事务的性能无法得到保证，而且C/S/S的特点，无需做到应用服务地址的透明性。也就是说，当用户登陆业务系统后，除非服务当机否则客户端将一直连接此应用服务器。这样，技术平台保证在一台应用服务器中实现无状态服务下的事务控制即可。更深入的分析下去，技术平台如果实现服务容器机制的话，则更容易实现和ADO.NET事务同样性能的事务控制。另外，技术平台可自动判断在数据提交的时候是否需要启动事务控制，以节省资源和提高性能。

l         并发：具体实现的地方。由于离线操作数据库的模式适合分布式应用，所以大部分业务设计会采用乐观锁机制，技术平台应该对此机制提供全面的实现方案和技术支持，比如“后进有效”、“时间戳”等等方法或变种。一个常见的业务场景是当业务层修改数据时需要锁定某些关键记录，此时技术平台根据业务组件的设置，自动锁住（打时间戳）这些记录，当提交数据时进行校验和释放等动作；另外，释放那些因非正常故障等中断而造成的“游离”锁，诸如此类的异常处理，都是由技术平台实现的。作为业务开发人员来说，他仅需在业务组件里通过技术平台提供的接口，定义哪些业务实体做编辑的时候需要锁定对应的记录，还要通过一些事件的触发感知到技术平台做了哪些动作（被占位、释放占位、处理异常。。。）以改变自己的行为。除此之外，都交由技术平台实现。

l         存储过程：提供业务过程层标准的通道来调用现存储过程，业务过程层不需要知道或依赖于数据库架构。

l         异常管理：截获数据访问层处理数据过程中产生的异常并传递到上层。配合日志管理模块对异常进行分类管理。

l         数据变动跟踪：业务开发人员仅需在业务实体类中进行定义，技术平台在此自动将数据变动情况进行记录。

l         双语支持：根据用户登陆时所选择的语言，对数据处理过程出现的提示信息和异常信息进行字符串替换。业务开发人员仅需将这些资源信息进行注册即可，由技术平台进行匹配。

供业务开发人员配置的接口：

l         数据库连接串：需要加密保存在应用服务器端，运行期由数据访问层获取和应用，不需暴露到业务过程层以上。

4           授权与安全性

技术平台提供业务开发人员标准的登陆界面组件，通过此组件，运行期供用户输入工号、口令、修改口令、选择双语、登陆服务IP（由技术平台管理IP列表并可在用户不指定具体服务的情况下自动连接资源占用少的应用服务器），负责用户登陆的权限校验和管理。而在设计期，业务开发人员仅需通过属性来达到个性化、友好性强的界面配置。

技术平台透明地实现上下文的信息传递，在各个物理层维持登陆用户的角色权限及其他信息，业务组件的设计开发不用关心这些上下文的传递到底是怎么运作的，只要在需要的时候，调用技术平台提供的接口函数，就能拿到并使用即可。

结合UI框架、业务组件框架（业务实体、DataSet），可完整地自动实现用户权限的校验和提示。业务组件框架要实现的部分，已经在业务实体的论述中详细讨论了，DataSet很类似，都一样可以在技术平台中实现。此处重点描述UI框架需要实现的权限控制。

用户权限在数据层是以这样的形式描述的：

l         表的浏览权限

l         表记录的增删改权限、存储过程的调用权限

l         表记录字段的读写权限

用户权限在业务层是以这样的形式描述的：

l         对象集合的浏览权限

l         对象的增删改权限、对象过程的调用权限

l         对象属性的读写权限

用户权限在UI层是以这样的形式描述的：

l         记录列表所在窗体是否允许弹出、弹出窗体时哪些记录列表是允许浏览的

l         记录的增删改、过程所对应的功能键是否允许点击（如按钮灰掉）或者干脆隐藏

l         记录内容对应的数据感知控件是否允许输入（如输入框灰掉）或者干脆隐藏

从上至下分为三个等级，依次约束。

此分析也可看出对象的增删改其实是过程的一种特例，所以为什么有那样的设计，就是对表记录的增删改也写成存储过程供系统调用（技术平台要是这么做的话，需要实现自动构建这些存储过程的能力，而业务开发人员无需关心和管理）。

UI框架从业务组件框架获得的是这些定义信息，从而实现菜单、按钮等导航控件的权限控制。这些控制由技术平台自动完成，业务开发人员仅需定义导航控件及其item与业务类、业务过程的对应关系即可。

5           分布式框架的封装

前文已提到，这里再着重描述。

实现封装的目的，是为了将业务代码的实现与具体的技术实现无关，提高了业务代码的可移植能力，延长产品的生命周期；而对于业务开发人员来说，则是彻底的技术透明感，他们仅需针对“业务过程代理”和“业务过程门户”提供的接口进行编程即可，再次降低了技术门槛。

对于开发人员来说，写业务组件代码和普通的类，在形式上没有任何区别（实质还是不同的，但这已不是技术问题，而是业务系统分析和业务系统架构问题）。

其实，“业务过程代理”和“业务过程门户”的接口在常规的代码设计中也是不用直接调用的，因为这些接口又被业务实体基类进行了二次封装，并实现了在业务类上CRUD等标准的处理过程。

针对业务开发人员来说，类似"ServiceBaseAddress"的配置信息也是无需关心的。为什么？因为结合前文的“登陆界面组件”，技术平台自然而然地可以管理上这些连接信息。

技术平台还实现了标准的CRUD服务接口，所以这些也是不用业务开发人员操心的。

那么对于其他业务组件自定义的服务接口又是如何管理呢？仍然是做配置管理（不一定是配置文件），只是配置管理是自动完成的，是通过组件注册的方式，也就是通过前文所述的组件容器进行注册。技术平台按照系统模块的层次结构管理上这些业务组件，业务开发人员无需关心配置管理的实现细节和具体存放位置，只需在技术平台提供的浏览界面上查看服务接口的层次结构，以便辅助分析系统设计、服务接口设计的合理性。这样，从技术手段解决开发过程中接口管理繁琐和容易冲突的问题。