最近很多网友问我同样的问题，那就是J-Hi与其它的平台类产品有什么区别？它有哪些独特的特点。实际在我看来J-Hi与目前任何其它平台类的产品的出发点或称之为初宗都是相同的，那就是想解决如何使开发更快速、更高效，如何降低项目的成本（不只是快速开发所带来的成本降低，也包括项目的管理成本）。
AD：
最近很多网友问我同样的问题，那就是J-Hi与其它的平台类产品有什么区别?它有哪些独特的特点。实际在我看来J-Hi与目前任何其它平台类的产品的出发点或称之为初宗都是相同的，那就是想解决如何使开发更快速、更高效，如何降低项目的成本(不只是快速开发所带来的成本降低，也包括项目的管理成本)。
总的来说，目前市场上的平台类产品所采用的核心技术无非两种，一种是模型驱动(后台有一个模型引擎来负责解析与计算这些业务模型从而得到预期的运算结果);另一种是代码生成(按照定义的模型通过生成器生成全部源文件)。从技术本身来看，这两种技术都不算什么新鲜东西，只是随着计算机运算能力的提高，相关技术的不断成熟，使这两种技术应用于业务开发平台成为可能，因此单纯从技术先进性来看，那我觉得都没有什么在技术可以称道的地方。反之，平台它是多种技术的融合体，尤其是业务开发平台不只包括技术本身还会包含一些通用的业务以及一些开发工具。因为这些的差异，就形成了各类平台产品的差异性。在此让我们来分析一下J-Hi Java快速开发平台自身的特点(即与其它平台的不同之处)：
快速的按需动态搭建
目前平台支持的框架有：webwork、struts2、spring、hibernate、ibatis2、ibatis3，对于这些框架您可以通过可视化(J-HI Studio，eclipse插件)的方式随意组合，通过工程创建向导，自动化的按照你所选择的框架快速的动态搭建起开发工程。我们之所以将J-Hi做成多框架动态搭建，主要是考虑到不同企业的开发团队对技术的倾向性会有很大差别，比如对于ORM有的人就喜欢hibernate，而有的人就觉得hibernate太强硬，喜欢用半自动化的ibatis。J-Hi基于这个目的为开发者提供了更多的可选择性。在此要注意对于平台多框架的集成并不象一般意思上的集成(即几个框架拼接在一起就可以象appfuse一样)，因为平台的集成还要包括很多通用业务并且与数据库表是有关系的(一般搭建多框架是没有业务的所有的东西都要由你亲自去开发，而平台会有很多的业务已经预留在平台中)。举个例子：比如安全管理，这是平台的一个通用业务包括角色、权限等。在切换到不同的框架比如struts或webwork;hibernate或ibatis时，平台的底层要自动的适应这种变化，这是有一定的创新点的J。当然我们以后还会集成更多、更优秀的框架在平台之中，比如SpringMVC，SpringJDBC等等，在数据库端我们也会再多支持一些数据库，当然集成数据库也不是传统意义上的只是一个数据库连接，而是针对不同的数据库差异会做不同的方言，不同的数据库脚本还要有相应的生成模板等等。
因此你会发现快速按需动态搭建，并不是传统意义上的多框架集成那么简单，而是对应每一种框架(数据库)平台都会提供一套完整的解决方案。总之多框架集成对于J-Hi来说，是牵一发而动全身的事情，变动一个框架，包括每一个页面，每一个java类，每一个配置文件都要随之而动态的变化。因此它是系统级的工程而非简单的多个框架拼接。
完整而系统的生成方案
代码生成或生成器这实际上在十年前就已经有的东西，无论是实现原理还是具体的工具都不是新鲜事物。J-Hi之所以将代码生成也算作自己的特色，是因为它的完整性与系统性。从完整性来看，J-Hi的生成是一套含盖从数据库底层一直到页面端全部的解决方案，包括数据库表;权限、菜单、多语言等相关基础数据;java类文件;JSP、js文件;相关配置文件等等，因此保证了生成即可运行，从单元体上来看生成文件是完整的，是可独立运行的。从系统性来看，生成的文件是随着你选择的框架不同而不同的，生成的基础是随着框架与数据库的差异而随需变化，系统的解决了生成器的僵硬性，从而灵活的适应开发环境。因此J-Hi的生成方案是系统的，是适应不同框架与数据库的生成方案的。
平台到底生成了些什么?
组件化
在软件世界里组件这个概念真是千差万别，每个系统与工具软件对组件都有各自不同的定义。尤其在Java世界里更是如此，小的从一个页面元素一直到大的一个业务功能系统，在各自的领域都会给它们定义为组件。按照《计算机百科全书》给组件的定义：是软件系统中具有相对独立功能、接口由契约指定、和语境有明显依赖关系、可独立部署、可组装的软件实体。由此定义我们来谈一下J-Hi Java快速开发平台对组件的理解与解决方案。
实际上说到底无非是对组件颗粒的划分问题，在不同的条件与环境下组件的作用与功能会有很大差异，其次在定义组件时要保证功能的相对独立并且可组装可部署，由此J-Hi将组件根据用途与范围的不同划分为如下四类组件类型：技术组件、实体组件、业务组件、系统组件，它们之间的关系是逐级递进，互为基础的。
在我们在深入探讨之前，先来简单的解释一下上图中各种组件类型之间的关系。比如一个OA系统我们就可以把这理解为一个系统组件，而多个系统组件(仓储系统、人力系统等)可以动态搭建更大的应用系统(ERP)。每个系统组件下会有多个业务组件，例如在OA系统下会有报销单、会议管理等多个业务组件。因为大部分业务组件之间一般都是松藕合的，所业务组件可以无缝的迁移到其它的系统组件中，即实现业务组件可复用性。而在一个业务组件下会有一个或多个实体组件够成，我们还以报销单业务组件为例，在报销单最少会有报销单及报销单明细两个实体组件，一个实体您可以理解成与数据库对应的一张表，实体之间可以继承、一个实体可以有多个子实体。但实体不仅仅是数据库表，它包括从页面到数据库表之间的全部代码实现同时包括CURD所有操作的功能单元。对于实体组件我们会在后面详细讨论。最后是技术组件，在J-Hi中技术组件可以说是一个抽象的概念，一个技术组件就是一个技术功能单元，它可能是一套生成模版，一个框架的支持，一套API(比如对短信、全文检索的支持等)
实体组件：J-Hi将一个实体组件定义为一个集合单元，它不仅仅包括数据库表还包括对该数据库表的基础操作(增、删、查、改);包括前端的展示面页;包括该实体的权限、菜单、配置信息;还包括它与其它实体的交互操作。当然一个实体组件颗粒度还是太小，还不能完整的描述一个业务功能。但实体组件相对来说有一定的独立性，可以集成一个集合单元，J-Hi就是以实体组件为基础实现更大粒度的集成，从而实现对一个完整业务的描述。
业务组件：实际上一个业务组件J-Hi将它对应于一个服务，服务可以认为是一个业务功能模块，用以描述完整的业务模式，具体相对的业务独立性。在服务内代码间是高聚集的，因为一个服务就是一套完整的业务，在设计服务时应尽最大限度的降低服务与服务之间的藕合度。因为在这个样一个理论基础上去设计，就可以实现业务组件无缝的在各系统之间的可移植性。因为组件的定义还要可以独立的组装与部署，因此我们开发平台的附属性产品——Hi平台产品集成工具，它主要是由发布器与部署器组成，以更方便的实现业务组件的迁移。
开发发布器与部署器的目的就是通过可视化的方式，实现跨数据库数据与跨应用系统的业务组件迁移。可以将业务组件看作一个独立的业务单元，可以无缝的集成于任何以J-Hi平台开发的项目中去。从而真正达到随需组合，动态搭建实际的业务系统，真正的实现业务组件的复用，降低不必要的重复开发。
系统组件：从业务功能上来看系统组件不过是多个业务组件的拼接，更大一级的业务封装。理论上系统组件与系统组件之间应满足绝对的隔离性，即使是有通信，应该也是通过第三方来进行数据交互(常用的解决方式有两种一种是中间数据库;第二种是webservice)。但如果是基于平台开发，这种无谓的工作量可以降低很少，甚至可以不需要第三方的交互技术。只要保证两个系统间的通信接口就要以轻松实现。系统组件的迁移也可以通过发布器与部署器来实现。
技术组件：从技术角度来看，J-Hi与其它的技术组件差别不大。无非是基于平台再开发一些技术组件，比如对 SpringMVC、SpringJDBC、DB2数据库等的支持，页面端也会再集成象DWZ或simpleframework，我们也会再提供更多的页面端的生成模版，以此类推，平台的技术组件会在技术的不同层面进行扩展。但与其它的技术组件不同之处在于，实现类似于插件一样的可插拔，随需织入。