东软Unieap平台

东软Unieap平台

 

开发环境与技术栈

操作系统	WINDOS7
数据库	Oracle
开发语言	JAVA
版本控制工具	git
框架	Unieap是基于现在主流的JAVA开发框架（Hibernate,Strust,Spring），封装了一些方法。所以也可以认为后台技术栈其实就是Hibernate+Strust+Spring。前端的框架也封装在了Unieap中。
SOA	采用的是阿里的框架dubbox，该框架现在主要由当当网来维护。
软件开发过程	敏捷软件开发scrum

 

 

东软Unieap平台简介

 

 

平台是基于J2EE平台的应用开发框架，为用户提供一致的规范和统一的标准，"组件化"的架构特征为规划业务用用奠定基础。

UniEAP以资产库为核心的逻辑架构主要划分为表现层（Presentation Layer），业务逻辑层（Business Logic Layer），数据层（Data Source Layer），基础框架（Infrastructure Layer）四个层次。

层次分明的MVC框架

Unieap基于MVC框架进行扩展，通过工具能够辅助生成大量繁琐的代码和配置文件，与模型驱动架构的思想结合起来，极大地提供开发人员的编码效率以及减少代码出错的几率。强大的数据绑定机制把表现层组件及业务层组件很好地衔接在一起，能够及时把表现层数据的状态变化反映给业务层，根据这些状态变化，业务层就能很轻松地把数据的变化同步到数据库中，以保证数据的一致性。

元模型驱动的设计器和运行期架构

基于模型驱动开发的业务基础平台，是以元数据模型来定义和约束组件。基于元数据模型驱动开发的思想，提供稳定且与技术平台无关的各类元数据模型。通过元数据模型沉淀业务需求，通过模型配置适应需求变化。

统一的开发平台

借助统一的平台和工具的形式，固化技术框架，规范，屏蔽技术细节并支持敏捷开发方法，为IT人员提供业务开发、运行、管理的统一手段，确保架构和规范的落地，实现业务与技术的统一。在统一的架构和规范下，逐步固化下来的IT系统作为可复用的业务模块，帮组企业资产积累资产，提高开发效率降低开发难度，提供系统的质量和稳定性。

基于软件产品线的应用开发框架

产品线架构是实现系统化复用的基础，UniEAP公共的软件产品线架构对所有在不同的产品中使用的组件定义了单一的环境，保证了不需要考虑相关类似功能组件的重复开发，只需要考虑它们的工作环境。以资产库位核心的架构平台和完备的资产开发和管理工具，支持以复用为目的的组件设计，开发和维护，通过大粒度地组件装配完成产品建造。并且，Unieap提供了丰富的基础组件与业务组件。

 

 

我对东软Unieap平台的一些思考

项目的目录

一个UniEAP工程主要由软件组件（Software Component）和开发组件组成

软件组件(SC)工程结构如下图所示

开发组件(DC)工程结构如下图所示

工程中的每个开发组件都可以引用其他的开发组件，也就是说每个开发组件都可以复用

 

开发组件的Metamodel文件夹中包含本开发组件下的各类模型定义文件

BO模型就是传统软件设计中的Service层

DAO模型就是传统软件设计中的Dao层

ENTITY和DTO模型就是数据实体，其中ENTITY直接是数据库表的对应实体（就是JavaBean），DTO数据传输层，当单一的实体满足不了业务要求的时候就需要该模型。

VIEW模型就是传统MVC中的视图层

 

其实就是传统的MVC模型，MVC模型应该可以说是现在的业内标准了。

接着下去我说一下平台基于的框架在平台中所扮演的角色。

Hibernate或者现在将要整合上去的Mybatis在平台中扮演着持久层的角色，他们都是ORM框架，即通过他们把数据库的表和实体类关联起来，方便我们访问数据库。

Spring在平台中主要用来对JavaBean的管理

Strust主要用来对页面跳转进行控制

 

这些框架基本上都是基于配置的。其实刚开始的时候我也很疑惑为什么框架一般都要写很多配置文件，配置文件始终没有代码来得有逻辑性。但是当我在开发一个功能Excel导入的时候，我才觉得配置文件的好处。需求是多变的，这是无法避免的事实，可能你今天有这样的需求，明天有那样的需求，甚至有时还不知道自己的需求到底是什么。所以在做Excel导入的时候，如果你把每列的对应关系都写在逻辑代码中的话，后期维护起来是非常麻烦的，只要你的需求一改的话，就要改原代码。如果这时候你把对应关系写在配置文件中的话，维护起来相对就比较方便了。首先所有相关字段配置都在一起，一目了然。其次如果项目已经在运行了的话，你改配置文件项目也不用再从新启动。

 

在平台的学习中有"软件组件"和"开发组件"这种概念，在我的理解中组件是具有一定的独立功能也就是说组件和组件之间的耦合性比较小，并且是一种粒度比较大的复用。在CRM的开发中，有"线索"，"商机"，"样机"等模块，这每一个模块都可以开发为一个组件，而且组件之间是有关联的比如"线索"模块就是为了过滤一部分潜在用户再转到"商机"模块成为正式用户。这种关系用小时候玩积木的比喻是很恰当的，比如你要搭建一个房子，你就要通过一些个各式各样的积木进行搭建。不同的积木块是相对比较独立的，他的内部是比较结实的，耦合性比较强，但是你搭的一个房子，积木块之间就需要项目接触，这种接触就是积木块之间的关联，但是这种关联是松耦合的，可拆卸的。每个积木可能同时和好几个其他积木进行接触。积木就是映射组件，房子就是映射一个项目。软件工程有一个很重要的设计概念，高内聚低耦合，组件就很好应用了这种概念。至于如果定义组件的粒度，到时什么样的规模算是组件，这个就不好定义了，这个要看具体的项目。以生物系统来做比喻吧，如果是一个细胞的话，细胞膜，细胞壁，细胞质就算一个组件了。但是对于组织来说的话，神经细胞，淋巴细胞，血细胞...才算一个组件。对于消化器官来说，上皮组织，结缔组织，肌肉组织...才能算一个组件。所以组件的粒度要看你针对的是什么规模的代码。

 

 

我觉平台中的很多设计是很有借鉴意义的。这里我列举我学习时候认为很不错的思想。对于像OA等业务开发的系统，基本上是以数据为中心的。需求的变更基本上是围绕着表结构和字段的变更。所以平台基本上是围绕着数据来进行设计的。对于每一个VIEW或者VIEWC，VIEWC是可以嵌入到VIEW中的组件，都会绑定一个数据集或多个数据集。数据集是由实体的属性组成，即直接对应数据库中的表的字段。平台在设计的时候就已经很好的把这些封装好了。所以你在开发时候，就可以很方便的使用，好像什么都不用做。但是这种封装是基于一定的规则的，你必须要遵守这些规则。就像那些框架的使用一样，也是要遵守相应框架的规则的。其中最重要的规则之一就是命名规则，框架之所以可以帮你做很多自动化的事情，很关键一个就是它是根据字段的名字，进行映射的。我觉得每一个框架的诞生都是由程序员长期写相同的代码，然后思考如果把这些相同的代码提取出来，然后放在配置中只要进行简单配置就好了，这样既减少了重复的代码同时也方便项目的可维护性和可扩展性。VIEW中的数据集，具体绑定在form表单或者grid表单，这是两种最常用的展示数据的控件。后台取到的form或者grid的数据就直接是JavaBean对象，这样减少了一些繁琐的操作。刚才也说过平台的很多东西都是基于配置的，这样也方面部署，平台的表现层框架采用的是strust。

这样我们写页面的跳转就可以是基于配置文件来写的。而Unieap平台又对这一框架进行了封装，对于页面的跳转，平台直接在前台写脚本语句有可以了。

 

 

对于中间件的理解，由于之前也没有什么概念，网上对于中间件的定义也千奇百怪，这里我引用维基百科上面的定义：

Middleware is computer software that provides services to software application beyond those available from operating system. It can be described as "software glue". Middleware makes it easier for software developers to implement communication and input/output, so they can focus on the specific purpose of their application.

中间件是一种在操作系统之上的为应用软件提供服务的软件。它可以被描述为"软件胶水"。中间件可以为软件开发者提供更加容易的软件间的通信和输入\输出，这样开发者就可以把精力集中在这些为了满足特定需求的软件开发上面。

Database access services are often characterised as middleware. Some of them are language specific implementations and support heterogeneous features and other related communication features. Examples of database-oriented middleware include ODBC,JDBC and transaction processing monitors.

数据访问服务通常被描述为中间件。他们其中的一些是用特定的语言实现的并且支持各式各样的功能，而其他的一些和通信的功能紧密相连。例如数据库中间件包括ODBC，JDBC和事物进程监控。

这里我就把JDBC理解成一种数据库访问的中间件。在东软的Unieap平台中ORM框架使用的Hibernate，我就说一下Hibernate和JDBC之间的关系。

Hibernate是jdbc的轻量级封装，包括jdbc的与数据库的连接（用hibernate.property的配置文件实现当然本质是封装了jdbc的forname），和查询，删除等代码，都用面向对象的思想用代码联系起来，hibernate通过hbm 配置文件把po类的字段和数据库的字段关联起来比如数据库的id,在po类中就是pravite Long id; public Long getId() public setId(Long id);然后hql语句也是面向对象的，它的查询语句不是查询数据库而是查询类的,这些实现的魔法就是xml文件，其实hibernate=封装的jdbc+xml文件

以此来说的话，我觉得框架是对中间件的一种封装，使中间件更容易的被使用。