张昊

2. 这项技术有什么优点?是否已经在实践中证实呢?

3. 哪些领域能运用这项技术，您能有一些好的建议么?

4. 对于刚刚接触J-HI这项技术的人群，有什么好的学习建议

       J-Hi设计自己的查询过滤器而没有直接采用Hibernate的Criteria，是出于以下两个原因：

1、Hibernate的Criteria的功能是很强大，但在使用上还是比较繁琐。因此J-Hi想从用户使用的简单易用性上考虑设计一款查询过滤器。

2、J-Hi是一款跨ORM的多框架平台，不能拘泥一种只在Hibernate适用的产品。因此从设计角度考虑，J-Hi对于查询过滤功能必须要有一个中间层，从而使适应多ORM框架成为可能。

       下面让我们来分析一下对于SQL的查询具体应该考虑些什么

1、                                          1、字段名            数据库表的字段名

2、                                          2、操作符            比如大于、小于……。还会包括一些特殊的操作符如like和in

3、                                          3、NO                 NO操作符是对操作符的补充，只有in和lik也会有no

4、                                          4、值                   对应字段类型的具体值，如字符串就要加引号，日期就要做转换

5、                                          5、空值               空值是特殊值，表述形式如IS NULL或IS NOT NULL

6、                                          6、关系符            两个查询条件之间的关系包括三种 AND OR NOT

7、                                          7、优前级            通过左右括号来控制查询条件的优前级

8、                                          8、通配符            如果是like操作符，在值的左侧或是右侧或两侧都可以通过%来控制值的匹配条件

对于java来说，无非就是考虑如何将上述的描述通过对象化的方式实现

先让我们用例说明：

       Filter filter = FilterFactory.getSimpleFilter("name", "马超");

首先所有的过滤器都必须由FilterFactory(过滤器工厂)创建，参数依次为

name：POJO的属性名的字符串,可以通过.级联如(org.id);

value：待过滤的过滤值

oprtion：操作符，提供多种操作符，具体参见javadoc

relation：关系符，两个过滤器之间的关系，如AND / OR / NOT

过滤器可以通过addCondition方法累加过滤条件，例如：

filter.addCondition("name", "赵云", Filter.OPERATOR_EQ,Filter.RELATION_OR);

调用addCondtion()方法返回是条件累加后的Filter，因此你可以一直不断的调用addCondtion()方法，而不用每做一个过滤条件就创建一个新的Flter。

也可以通过addFilter方法将两个过滤器连接合并在一起

       otherFilter.addFilter(filter, Filter.RELATION_AND);

因为一个过滤器会有多个查询条件，因此在通过addFilter()将两上过滤器进行合并时会对这两个过滤器自动加左右括号。对应sql为：

(otherFilter的查询条件) and (name like ‘%马超%’ or name = ‘赵云’ )

       与addFilter对应，J-Hi还提供了removeFilter的功能，目的是通过目标过滤器中删除曾经加进来的子过滤器

              otherFilter.remove(filter);

       对字符串的操作，如果不加操作符那么系统默认采用like操作符，并且左右两侧均会加通配符，为了解决通配符的问题，J-Hi提供了

Filter likeFilter = FilterFactory.getLikeFilter("name", "马超", Filter.RELATION_AND, LikeFilter. LIKE_CONTROLER_LEFT );

对应的SQL语名为：name like ‘%马超’

       如果对null或非null做过滤

     FilterFactory.getSimpleFilter(propertyName, null, Filter.OPERATOR_EQ);

FilterFactory.getSimpleFilter(propertyName, null, Filter.OPERATOR_NOT_EQ);

对应的SQL语句分别为：propertyName IS NULL ; propertyName IS NOT NULL

如果做包含(IN)做过滤

FilterFactory.getInFilter(propertyName, coll);

其中coll是java.util.Collection接口的对象

除此以外，J-Hi还提供了排序器

Sorter sorter = SorterFactory.getSimpleSort(propertyName, Sorter.ORDER_DESC);

Sorter.addSort(properyName1, Sorter.ORDER_ASC);

首先所有的排序器都必须由SorterFactory(过滤器工厂)创建，排序器可以通过addSort方法累加。也可以通过addSort方法将两个排序器连接合并在一起

具体的调用方法例如：

HiUserManager userMgr = (HiUserManager)SpringContextHolder.getBean(HiUser.class);

userMger.getObjects(filter,sorter);

总结：J-Hi的查询过滤器并没有象Hibernate的Criteria那么的强大，还不支持外连接与聚合。原因是这种大数据量的统计对ORM框架来实现在效率上并不是好的解决方案，再者实现上述功能增加了使用者操作的复杂度。荐于以上两个原因J-Hi的查询过滤器没有实现上述功能。

最近很多网友问我同样的问题，那就是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的生成方案是系统的，是适应不同框架与数据库的生成方案的。

平台到底生成了些什么？

组件化

J-Hi把组件划分为四类，技术组件、实体组件、业务组件与系统组件，具体内容请参见平台组件化

      自J-Hi正式发布以来（2011-1-14）已有三百多个爱好者加入我们的交流群，下载次数约1300次。随着使用者的增加逐渐增多，大家在使用中的疑问也越来越多。其中最多的问题就是生成器到底生成了些什么东西，下面以xxx服务，实体***为例，对生成的文件一一讲解：

数据库相关

对应不同的数据库J-Hi会生成不同的数据库脚本文件，生成的文件会临时存放在web/db目录下的相关数据库（MSSQL/MYSQL/ORACLE）子目录下，每次生成该目录下的文件都会清理一次。生成的文件如下：

xxx.sql    定义该服务下所有实体（枚举实体除外）的数据库表的创建

xxx_BaseData.sql用于对该服务下的实体，为系统表插入相关数据,系统表包括：菜单、权限、枚举等，通过该文件会将与实体相关的菜单信息，权限信息等一次性的插入到系统表中

Java相关

       因为Java含盖的框架有很多，采用不同的框架不同的技术生成的内容会有所不同，下面让我们按三层结构的原理划分说明：

数据访问层

       xxx.dao包为数据访问层的总包，对应不同的ORM框架还会有相应的子包，比如hibernate、ibatis(ibatis2)、ibatis3等子包。

       ***DAO.java：在dao包下这是个接口，用于规范不同框架之间的差异。

       hibernate子包：

***DAOHibernate.java：hibernate数据访问的具体实现类，该类继承BaseDAOHibernate，从而实现对hibernate的封装

***.hbm.xml：该文件是hibernate的映射文件

       我们之所以把ibatis的两个不同版本分两个子包来管理，是因为ibatis2与ibatis3在底层实现上已经有很大的差异，无论是内部运行原理还是配置文件基本上是颠覆性的变化。

       ibatis子包

              ***DAOIbatis.java：ibatis2数据访问的具实体现类，该类继承BaseDAOIbatis，从而实现对Ibatis2的封装

              ***.ism.xml：ibatis2的映射文件，之所以后缀叫ism是指ibatis sql mapping

      ibatis3子包

              ***DAOIbatis3.java：ibatis3数据访问的具实体现类，该类继承BaseDAOIbatis，从而实现对Ibatis3的封装

              ***.ism3.xml：ibatis3的映射文件，之所以后缀叫ism是指ibatis3 sql mapping

业务逻辑层

       业务逻辑层J-Hi采用的是spring，因此大体上与spring的标准结构完全相同

       xxx.service包为业务逻辑层的总包，接口定义在该包下

       ***Manager.java：业务逻辑的接口类文件，缺省生成的是实体的增删查改方法，如果在业务逻辑层中想做权限控制，可以调用*Security***()方法

       xxx.service.impl包下的

       ***ManagerImpl.java：是业务逻辑的具体类，该类继承ManagerImpl类。如果是特定的业务逻辑一定要在该类中通过手写代码的形式实现之

       appContext-xxx.xml：是spring的配置文件，放在置在xxx包下

表现层

       xxx.action包为表现层的总包，对应不同的表现层框架会有相应的子包，比如webwork、struts等子包。

       ***PageInfo.java：在action总包下，该类是与框架无关的，实际上该类记录页面信息的一个POJO，信息主要包括三部分：1）翻页（page）：行数、当前页数等；2)过滤器(filter)：即查询条件；3）排序器(sorter)：即正序倒序

       webwork子包：

***ListAction.java：查询页面时所调用的动作

***.RemoveActoin.java：删除记录时所调用的动作

***.RemoveAllActoin.java：批量删除时所调用的动作

***SaveAction.java：保存记录时所调用的动作

***.ViewAllActoin.java：查看记录时所调用的动作

xwork-xxx.xml：webwork的配置文件

       与webwork相比，struts的类文件只有一个，所以的动作都是通过方法命名调用实现的，我们之所以做成两种生成方式，是想考虑用户会有个自不同的编程偏好，从而我们为些在不同框架间提供两种生成模式，以适应这种编程偏好的差异

       struts子包：

       平台目前舍弃了对struts1.x的支持，所以与struts相关都是以struts2为前提的

       ***Action.java：该Action包括了所有的页面调用动作，通过方法命名进行调度

       struts-xxx.xml：struts2的配置文件

POJO及其它

       在xxx.model包为POJO的总包，一个POJO实际上是由两个类文件组成的，即

       ***Abstract.java：该类是POJO的抽象类

       ***.java：该类是POJO的具体类

       之所以这样做是为了避免手写的代码会被生成器生成的文件所覆盖

       ***.java：如果在定义是有枚举实体，在model包下还有会生对应枚举实体的常量类文件

       ***-conversion.properties：如果实体有从实体，也就是主从结构，生成器对应主实体生成该文件，其目的是为了适应表现层框架对页面信息的对象化封装

       xxx--security.properties：该文件放置在xxx包下，是权限的映射信息的配置文件

页面相关

       以后生成器会根据所选模版不同，而对应生成的页面会有很大差异，现在以目前平台的经典模版为例

       ***List.jsp：查询页面

       ***Edit.jsp：编辑页面

       ***View.jsp：查看页面

       ***.js：与JSP文件应对应的javascript文件

源数据相关

       ***.hsc.xml 对应每个服务，平台在WEB-INF/matadate目录下都会生成一个源数据的描述文件。该文件记录了定义了模型的全部信息。hsc的意义为：hi service config

基于平台生成器避免手动代码被覆盖的解决方案

如果您采用本平台开发，理论上80%以上的代码都是生成出来的。这样就带来了一个新问题—如何保证我手动改写或添加的代码不会被生成器生成的文件所覆盖?

考虑到上述问题生成器在生成文件时有如下规则：

生成器会反复生成并覆盖以下类与文件：

  i.        model.original包下的抽象类

  ii.        action包下***PageInfo类

  iii.        model包下的***.hbm.xml文件

  iv.        服务根包下的appContext-***.xml文件

  v.        服务根包下的***-security.properties文件

  vi.        src根下的xwork-***.xml文件

除上述文件外，生成器对生成其它文件时均会判断是否以存在，如果存生就不再生成也不会覆盖已生成或手动修改类或配置文件的内容

从反复生成的文件规则上可以看出，生成器只会反复生成：

1）  与实体属性密切相关的类或配置文件如模型的抽象类与***PageInfo、***.hbm.xml，因为实体中的属性名称或数量发生变化，生成器要适应对实体属性的变化

2）  与整个服务相关的配置文件如xwork-***.xml、appContext-***.xml等等，因为一个服务下会有多个实体，生成器要适应服务下实体数据库的增减

3）  对于那些与实体相关并且不与服务或实体属性相关的类生成器却只会生成一次如dao、service、action下的所有类，以保证您手写的代码不会被生成器所覆盖

在基于平台开发时，因采用生成器生成所以可以使用如下解决方案来避免您手写的代码或配置不会被生成器所覆盖

               i.      如果您要对模型类实现某个接口或方法，请改写model包下的具体类，该类只会生成一次，注意千万不要修改original包下抽象中的内容

                ii.      如果您要对表现层的配置文件做修改，以xwork-test.xml为例，操作应该是1）新建一个xwork-test-customer.xml配置文 件，2）将您要修改或要增加的actoin写在该文件中(即使action名与xwork-test.xml只的action名重复也没有关系，系统会以 您的action为最高优先级)，3）在xwork.xml文件中引入该配置文件<include file="xwork-test-customer.xml" />注意一定要放在xwork-customer.xml引用的下面。只有这样复名的action才会优先调用您的配置

                iii.      如果您要对业务层的配置文件做修改，以appContext-text.xml为例，操作应该是1)新建一个appContext-test- customer.xml配置文件，2）在该文件中加入您自己的配置信息。注意新建的文件名必须以appContext开头。

               iv.      如果您要对权限配置文件做修改，以test-security.properties为例，操作应该是1)新建一个test-customer- security.properties配置文件，2）在该文件中加入您的配置信息。注意新建的文件名必须以-security结尾。最后如果您想删除生 成的配置文件中某些配置项（即对某些url或方法不要求做权限控制），推荐在整个项目做完后统一处理。

初入江湖

在我看来程序员这一职业所走过的道路，就象我们每个人心目那个魂牵梦系的江湖。初入江湖时只是一个根骨不错全无武功，但梦想成为一代大侠的毛头小子，这时最想得到的是一把举世无双的神兵利器，以为有了它就可以扬名立万创下不世的功业。这就好比一个想成为程序员只会了一点点java基础的刚出校门的学生，怀揣着自己人生的梦想踌躇满志的步入社会，而对他来说第一要用到的兵器就是Eclipse。因此对于我们程序员来说一上手就有一件神兵利器是一件幸事，然后真正能达到运用之妙，存乎一心的地步还是因人而异；

投入门派

选好了兵器后步入江湖的第二件事情就是要加入一个门派；因为在java世界里会有很多分支，有做手机或PDA的javaME，做网站或是企业级开发的JavaEE，这就好比武林中的各各门派，门派的不同功夫的套路、思想都会有很大的差别，一般来说江湖中的侠士们加入门派后都不会另投它派，程序员也一样选择了一个领域就很少有机会再涉足其它领域，所以选好门派是职业生涯中的一件大事，不可含糊。在武侠的世界里进入门派后一定是不分寒暑的苦练武功，可能会有拳术、剑术、棍术、枪术等等总之十八般武艺样样精通（象少林寺中的觉远，哈哈）；而在程序员的世界中也是一样，你要学会很多的框架，这些框架也会分为不同的类别，比如表现层的struts或webwork、数据访问层的hibernate或ibatis、业务逻辑层的spring与xml对象化交互的JAXB等等。真是套路繁杂，学无止境，看着一本本厚厚的能拍死自己的技术书籍，真是苦不堪言，然而正所谓师傅领进门修行在个人，更主要的是自己要日日精进，勤学苦练才能学到真正上层的武功。

内功修为

随着武功的境界的不断提高，一个闯荡江湖的大侠会逐渐发现功夫套路习得的多少对自己的功力并没有多大长进了，越来越发现内力的提升才是根本，而套路不过是枝叶而已；程序员也是一样随着学习框架的增加，会越来越关心设计思想的重要性，发现语言本身不过是思想的一种载体而已，用什么语言去实现已显得不那么重要，真正的达到“手中无剑，心中有剑”的上层功力。随着武功的精进内力修为的提高，逐渐会发现设计模式也不过是一种解决特定问题的一种设计方式，甚至是成为了一种思维定式，遇到问题会不加思索的会联想到指定的设计模式，真正的达到“手中无剑，心中亦无剑”。如果是做企业级开发的程序员会越来越关注于企业级开发的整体模式，发现像权限、工作流等等这些功能无非是千篇一律有模式可寻的东西。当发现这些规律并能充分利用好它们时就可以达到“重剑无锋，大巧不工”这种武功的最高境界。

侠之大者

       最后我想要说的就引用金庸大侠在《神雕侠侣》里面的一句原话吧，“侠之大者，为国为民”，对于J-HI平台它是免费的、开源的，我们整个团队希望为中国的开源事业尽到自己的一份绵薄之力，也希望大家在看过这本书后都能有自己的收获，也许这种收获不只是在技术上还包括对编程的热爱，对中国开源事业的热爱以及一个团队那颗颗热诚的心。

http://www.j-hi.net

J-Hi平台的市场定位与目标用户是什么？竞争对手又有哪些？

J-Hi自 诞生 之日起就把目标定位在如何解决开发的高效性上，这是我们的初衷也是我们的最终目的，对于高效性J-Hi对此的解决方案是：

1）易于上手，学习成本低：J-Hi没有自己的标准，J-Hi是标准的执行者与推广者。因此我们采用的都是大家很熟悉的成熟技术，如spring、hibernate、struts、ibaties、webwork

2）代码生成的方式：说到底J-Hi是程序员给程序员开发的工具，因为只有这样才会使项目开发更可控（从技术本身来说没有万能的工具，只有coding才是万能的）。J-Hi是想使程序员从千篇一律而又枯燥繁琐的重复代码中解放出来，通过代码生成的方式由生成器全部生成，而使开发人员把精力更多的去放在关注业务本身上。

3）平台的底层支撑：从技术上我们在J-Hi与其它框架的整合上做了一些工作，目的是使开发人员更方便的去调用，使代码编写起来更高效。而且不同框架的组合是动态搭建的，从而使您有更多的选择性，更适合开发人员的技术掌握情况。从业务上J-Hi提供了一些抽象的业务组件，比如组织机构、权限、菜单、任务调度、枚举（数据字典）、日志等等。

4）组件化模式：J-Hi认为每个服务就是一个业务组件，业务组件可以在不同的系统之间来回迁移，从而实现业务组件的复用性。从另一方面来看，也更有利于公司的技术与业务积累，不用做重复的工作。对于组件化我们会提供完整的文章后续讨论。

5）基于使项目管理更规范，从而使项目的开发更高效：因为代码生成所有的层次结构与编写方式都是规范的（即使是一个属性名），因此更方便开发人员的相互沟通与阅读，也是因为这个原因从而使人员流动的风险大大降低（继任者可以很快的读懂别人写的代码，很快的投入到工作中去。诚然新来的人还要了解业务，但对于开发人员来说他只要关心自己一部分的业务需求，而不用整个系统去了解需求）。

6）现在项目开发最大的问题是开发与文档的不同步：目前我们在这一部分已有自己的解决方案，但因为精力与资源有限还没有形成真正的产品化的东西L

对于J-Hi来说目标用户主要是中小型及大型但技术积累不足的软件公司和系统集成商。说到竞争对手，因为J-Hi是开源的，既然开源就应该抱着一个开放的心态我们没有真正的竞争对手。如果真说有的话，我想应该是想舍弃程序员实现非编码开发的产品吧！

J-Hi的有何创新点？优势又在哪里？

在说到创新点之前我想先说一下我们对创新的理解，什么是创新，我们觉得不过是在前人的基础上前进了那么一小步，大部分还是吃着前人嚼过的馍。我觉得Spring 的AOP在目前的主流技术里是最有创新的，但分析到最底层时也不过是动态代理（不过能运用到如此程度也不得不让人敬佩的五体投地）。严格意义的说平台没有创新只不过是十多年开发的经验积累，即便是有创新也只是对各种技术的融合，也是通过这种融合使使用者有更多的选择性。目前我们正在做与国内优秀框架的融合工作，包括DWZ和simpleframework。以后我们也会秉承这种思想，融合更多更优秀的东西加到J-Hi之中去。

对于J-Hi你们想怎样运作？是商业运作吗？

       是的，我们是商业。原因很简单在中国的开源大环境不好。象在国外一般都会有一些基金的支助或是代码捐赠，但中国现在我还没发现。大家都是兴趣，是对编程的一种热爱，而且大多都是兼职在做。我觉得大家的出发点都是好的但是可操作性太差，因为没有商业运作就很难提供优质的服务，没有好的服务也就抑制了产品的推广，没了用户群产品就不会有旺盛的生命力。我最大的愿望是：中国的开源团队联合起来！

那你们想如何通过平台盈利呢？

       现在我们想到的主要是通过服务与技术支持，当然J-Hi以后要走的路还很长，以后还要很多的事情要做，比如基于平台的增值组件，我们把增值组件划分为三种形式：

1、  开源组件：比如CRM、CMS、进销存等

2、  免费组件：比如：SpringMVC、SpringJDBC等

3、  收费组件：比如：报表系统、在线会议、工作流等

这么多的工作你们几个怎么可能完成呢？

我们的想法是J-Hi不只是一个开发工具，更是一个开放的生态社区，希望大家都能融入进来，也许前期我们会有一些投入，但我们的目的是想让更多的人加入到这个社区中来，大家共同工作，从而实现双赢，使每个付出的人都有收益。

你们的工作流为什么不开源？

       是就这个问题有很多的朋友问过我，有人还说我们是假开源伪开源。也许他们说得也有道理，但中国的开源环境我们也是没有办法的事。总不能饿着肚子做开源吧，生存是目前摆在我们团队最大的问题，如果生存都成问题，那还怎么可能把事情做下去呢。所以对此还请大家谅见，工作流开源对我们来说只是迟早的问题，而不是想着死抱着不放。

趋势

在当今的企业级开发过程中随着开源框架的不断成熟(稳定性与可维护性已不是问题)，如何快速提高开发效率,降低开发成本已成为急待解决的问题。为了解决上述问题各各大型的软件公司或是有五年以上经验积累的中、小型软件公司都会有各自的解决方案。或是制定完整的开发方案；或是有一个带一些业务的框架；或是有自己的开发工具。在这个大环境的驱动下也不乏一些专做开发平台的公司应运而生。究其原因，这是一种趋势，我们认为软件行业正在走着一条硬件的老路，在此我们先回顾一下硬件的发展道路

通过图不言自明，硬件正是通过是独立的单元不断向更大的集成的趋势，每个上一环节都是下一环节的单位，而下一环节是上一环节更大规模的集成。从本质上来看软件也与硬件的道路差不太多，如图：

融合

如果从严格的意义来说J-Hi没有什么创新点，技术创新不过是在前人的基础上多前进那么一小步，因此即便是有创新点也只是对各种技术的融合。有人说这叫“造轮子”，我们不想造轮子，也不想提出自己的开发规范。J-Hi的关注点主要制力于对优秀的框架与技术进行融合，使其更适合方便的使用。因此J-Hi是开放的，不同与其它以模型驱动的业务平台产品有自己的开发规则、脚本语言与操作方式成为了一个自封闭的系统。又因为J-Hi的开放性，利用的都是主流框架的开发规则(这些框架大家都耳熟能详，基础知识已不是问题)，从而降低开发人员的学习曲线，提高了开发速度。平台的开放性也注定了它会不断的融入进的元素，加入新的框架。不断的求新、求变、保证性能的稳定与功能的完善是它追求的目标。嗨！~~，象打个招呼这般简单实用是它的源动力（J-Hi名字的由来）。

尊重传统的开发模式

       程序开发是一种习惯，看惯了代码、写惯了coding，程序员很难接受无编码的开发形式，没了设计感觉扼杀了自己的创造力。而J-Hi完全尊重传统的开发模式，可以说是对传统开发模式的有益补充，补充在代码生成与组件的可移植性上。首先，是生成可以使您从枯燥的复重劳动中解放出来使您将精力更多的用于把握客户的业务需求；其次，所有代码无论是生成的还是底层代码都是对您可见的，您可以充分发挥你的创造力与创新精神，采用设计模式写出优质的代码；最后，平台的组件化更便于您与其它系统的整合（例如您在OA里做了一个报销管理，您可以通过发布器方便的将它移植到ERP系统或任何采用平台开发的系统中去）。

所有的一切只是为了提高速度降低成本

Hi平台的宗旨无非八个字“提高速度，降低成本”，在提高开发速度方面：

1）      Hi平台采用模式代码生成的方式会生成从数据库脚本、JAVA代码、JSP页面到相关配置文件所有文件，从而使您从枯燥繁琐的编辑配置文件写模式代的JAVA代码中解放出来。

2）      平台本身提供了很多通用的、可配置的功能模块（如权限管理、附件、枚举管理……）我们称之为通用组件。因为这些通用组件都是十分常用的，可以说在一个系统中它们无处不在，所以利用通用组件可以大大加快项目的开发速度。

3）      Hi平台底层是一个设计良好的框架，可以说融入了当今大多数主流的开源框架。通过向导的形式平台可以提供对不同框架间的一站式快速搭建。

4）      除之以外如何快速响应客户的需求的不断变化一直是做软件项目的一场噩梦，而Hi平台在这方面有一些自己的经验与尝试，即使是增、改数据库表字平台本身也有自己的解决方案。

在降低成本方面：

1）   风险成本，为了提供开发速度降低项目的经济成本采用平台或工具(即使是采用一些开源框架)这已是业界不可逆转的趋势。随着平台化产品的不断涌现，如何选择好的产品以降低风险已是作为决策层首当其冲考虑的问题。在这方面可以说Hi平台在同类的产品中风险是最低的，一、它是开源的没有任何瓶劲；二、它是代码生成的所有的一切均可见，J-Hi平台不发现制造规范只是java世界中主流规范的执行者，本身没有任何技术陷阱；三、可以说J-Hi平台是程序员为程序员开发的一个工具，它的开发模式与传统开发模式完全相同

2）   人力成本，快速开发本身就意味着人力成本的降低，对于企业来说通过平台可以将人员分出梯次从而进一步的控制人力成本。对于个人来说通过对J-Hi开源平台的学习(因为可以说平台本身就是目前很多主流框架的一个容器)，可以快速的提升自己的技能，特别是在企业级开发上，从而自身价值的提升。

3）   管理成本，人员的流动尤其是核心人员的流动一直是企业面临的棘手问题，而对应该问题的最好方式是在项目管理与开发上的标准化。J-Hi平台为开发的标准化提供了一个基础，原因在于代码生成无论是代码样式、风格及配置文件的规则完全相同。这样就保证无论人员如何流动这套标准是不会变化的。