Java快速开发平台:J-Hi 

            J-HI是一款JAVA WEB应用软件快速开发开源平台，主要服务于软件企业和传统行业企事业单位信息中心的开发人员，为他们提供一套完整的一站式的JAVA WEB应用软件快速开发解决方案。 

            J-HI是什么 

            J-HI是一款JAVA WEB应用软件快速开发开源平台，主要服务于软件企业和传统行业企事业单位信息中心的开发人员，为他们提供一套完整的一站式的JAVA WEB应用软件快速开发解决方案。 

            平台包括如下几个部分: 

            1、J-HI平台集成环境:J-HI团队开发了一个集成开发环境J-HI Studio，在此集成开发环境之上，开发人员能够快速搭建自己的开发环境，创建自己的模型，快速生成代码。 

            2、核心框架:平台为Java代码与JS代码之间提供了一套完整的面向对象的核心框架支撑系统，可以认为这是一个抽象层，无论是在页面表现上，还是 在 CURD的任意一层，平台均提供了最大限度的抽象。用以保证平台本身的可扩展性、稳定性及灵活性。J-HI平台中提供了大量的API(Java与JS)，为用户在开发过程中随需调用，从而进一步加快开发速度，保证代码质量。 

            3、业务平台功能:包括权限管理、组织结构、枚举管理、国际化管理、任务管理、日志管理、Excel报表管理、消息管理等。 

            4、工作流:包括工作流引擎及流程编辑器等。 

            J-HI有什么特点 

            1、基于业务模型，可以快速生成，提高大大提高开发速度。 

            2、与传统开发模式相同，是传统开发模式的有益补充。 

            3、更大的灵活性，无论是生成的源代码还是生成器模板，用户均可自由修改。 4、多框架支持，为您的开发提供了更大的可选择空间。 

            5、基础框架完全开源，用户可以按需自我调整(实际上平台底层已经非常强壮，无需调整)。 6、组件化管理，组件重用、扩展、移植更加方便。用户可以有选择的使用部分组件。 7、容易上手，无论是学习还是作用项目开发，平台容易掌握，学习曲线低。 8、优秀的学习资料，平台是多年经验积累的结果，您可以通过平台分析了解更多的技术解决方案，与设计思想。 

            为什么会选择J-HI 

            通过技术路线我们会发现无论是软件还是硬件，如今的系统越来越高精密，越来越复杂，需要掌握的知识也越来越多。J-HI平台本身就定位在“大规模集成”这一环节上，目的是将主流的框架集成于该平台当中，为用户呈显一个高效、稳定、可复用、低耦合、通用化并且功能齐全、用户体验友好的套件产品。J-HI平台的目的就是通过平台的集成能力，化繁为简。从而提高开发效率，让软件工程师将主要的精力放在最核心的业务逻辑上，而非写一堆的POJO类或页面导航的配置文件这些琐然无味又没有技术含量的工作中。 

            平台也是一个了解主流开源框架很好的学习工具，因为它本身是一个设计良好开放的框架，除了支持目前主流的表现层webwork、struts，业务层spring以及持久层HIbernate和ibatis开发框架，用户还可以通过扩展平台实现其它非主流的开发框架，例如页面可是vm/ftl/pdf等，在持久层上用户可以采用JDO等。并且所有文档及代码注释均采用中文，为快速了解平台及相关Java框架提拱一条便捷有效的学习途径。 

            J-HI平台的宗旨无非八个字“提高速度，降低成本”，在提高开发速度方面: 1) J-HI平台采用模式驱动代码生成的方式会生成从数据库脚本、Java代码、JSP页面到相关配置文件所有文件，从而使您从枯燥繁琐的编辑配置文件、写模式的Java代码(如POJO、Action、DAO)中解放出来。 

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

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

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

            在降低成本方面: 

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

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

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

            上图是在功能上对J-HI平台的高度概括。通过该图可以看出平台采用JavaEE接合Spring实现从数据库端直到业务端的全线贯通。从总的技术路线来看平台充分发挥 Spring IOC与AOP的强大功能，实现业务层两端(即表现层与持久层)的完全解藕与无缝集成。在此要强调这种集成并非传统意义上的提供一套简单的配置文件，而是结合业务对每个框架的集成均提供一套更符合业务、调用更友好的抽象层，抽象层除封装、集成外还提供一套客户可配置，扩展性良好的通用API。而对于颗粒度较大的功能项，我们以通用组件的形式发布于平台之中，如树的展示、对象化的树型结构等等。在页面表现上平台除提供可客户化扩展的标签库外，还为您提供一整套以ajax技术为核心的客户端，从而使用户感受更好，更像是web2.0技术实现。除此之外，平台更加贴近实际业务，提供了一些通用的应用服务，包括权限管理、组织结构、任务管理等等，对于

            通用的应用服务我们以后的版本中不断加入，可以看出平台是一个开放的不断扩充的集成开发工具。最后，生成器贯穿于所有层面，可以生成任何层面的文件与代码。 

            原文链接: 

            论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的生成方案是系统的，是适应不同框架与数据库的生成方案的。 

            平台到底生成了些什么? 

            组件化 

            在软件世界里组件这个概念真是千差万别，每个系统与工具软件对组件都有各自不同的定义。尤其在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，我们也会再提供更多的页面端的生成模版，以此类推，平台的技术组件会在技术的不同层面进行扩展。但与其它的技术组件不同之处在于，实现类似于插件一样的可插拔，随需织入。 

            J-Hi快速开发平台到底快速在哪里? 

            1、快速上手，降低学习曲线 

            对于刚刚接触J-Hi的人来说，它上手很容易，我们为每一个功能点都提供了悬浮帮助功能，即使没有任何资料(当然我们已提供了视频与开发文档)，您也可以通过向导与帮助在十分钟之内就可以创建出您自己的项目原型。 

            其次J-Hi平台采用的大都是大家耳熟能详的主流框架与技术，如果您对主流的框架有所了解，那么对J-Hi的学习就没有任何阻力了。 

            2、快速搭建开发环境 

            也许您因为项目或自身开发团队的不同会采用不同的框架技术，例如您团队中对struts2熟悉的人远远要比掌握webwork的工程师要多，或者在您的项目中统计分析的功能很多，您要考虑ORM的效率问题，而不得不放弃hibernate而采用ibatis或springJDBC，也许您还要考虑数据库问题等等。在搭建开发环境您一定会考虑很多因素，尽管搭建开发环境并不复杂，但还是不够自动化，还要手动的配置，费时费力。J-Hi为快速搭建开发环境提供合理的解决方案，您可以按需求动在此您可以选择不同的页面框架，并且我们提供了“预览”让您在搭建开发环境之前就可以看到搭建后的页面显示效果 在此您可以选择不同的数据库。 

            3、快速生成所有代码 

            通过建立或导入模式，您可以快速的生成所有代码与文件，并且在生成时会根据您选择的框架技术与数据库的不同而自动适配。 

            当然您还可以有选择的生成部分代码文件，例如只生成JSP页面，或只生成java代码。生成的

            java代码结构如下(因为我选择的框架是ibatis3+struts2，所以平台会自动匹配只生成与这两

            个框架相关的类文件，而不会生成无用的其它框架的东西): 

            4、快速解决在业务需求中的技术难点 

            一般我们在做项目开发时，总是要等到项目开发的中、后期才能去解决业务核心问题，因此很造成无法合理估计项目的技术风险。原因是复杂的业务总是要等到基础模块建好后才能进入到开发阶段，从而使解决核心的技术问题置后。我们以一个报销为例来做个简单说明，比如报销在审核后的业务逻辑很复杂并且有可能还要涉及到与其它的系统对接。一般来说我们总是要等到这个报销单建好，起码要有最基本的增删查改功能(即使没有页面也要有后台的代码)后才能进入到核心业务的开发，这就加大的技术风险，因为我们会很早的发现问题，但解决这些问题却远远的落后于发现这个问题，甚至到了开发的中、后期因为技术问题在底层上还要一改再改。而使用J-Hi可以很快的进入到业务核心的技术上，因为只要生成，基础功能就已经提供，甚至平台还为您提供了单元测试用例类，从而使您可以直指业务核心，将项目风险控制在最低。 5、通过提供通用的组件 

            平台提供了很多通用业务组件，例如组织机构、角色权限、报表、定时任务、菜单管理、日志管理、系统配置、附件上传等等，除此之外平台还提供了一些纯技术组件，例如树型结构、java脚本工具、编码生成器、可选择性的返回JSON对象等等。这些通用的业务组件与技术组件可以为您在开发过程节省很多时间，随需使用，从而大大降低开发速度。 

            6、通过服务的复用性提高开发速度 

            在介绍平台的服务复用性之前，让我们来举个例子。比如您做了一个OA项目其中有一个模块是报销管理这个模块很成熟，您已经在OA系统中应用了很久。现在又有一个ERP系统，您想把这个成熟的报销管理复制到ERP系统中，这样这个功能就不用在ERP系统中再做开发了。对于平台来说这就是服务的复用性，我们提供了一整套对服务复用性的解决方案，并且有自己的可视化工具。 

            我们叫它J-Hi整合工具，是用C#做的。它的作用: 

            1)可视化导入/导出数据库，并同时实现跨数据库，例如您可以在mysql上开发(导出)，开发完将所有的数据迁移到oracle上(导入)。 

            2)发布器，可视化将您开发的模块或系统自动发布成一个发布包(包括数据库、jar、文件[jsp、js、图片、配置文件等]还包括文件的片段[例如修改web.xml文件中的一部分内容]) 3)部署器，将发布包部署到开发的工程中，部署的内容见发布器的描述 

            4)实施器，对应的生产系统，我们通过FTP，将相应的文件与数据库自动部署到生产系统中 7、快速的部署与迁移 

            也许您正在为客户要求从SQLServer数据库改为Oracle而感到苦恼，因为这要做大量的数据迁移工作，或许您反复的将修改后的bug部署到生产环境中而郁闷，我想J-Hi通过它的整合工具为您提供了便捷的方式。具体的实现方式请参见上一节的介绍 

            8、开发人员可以快速的接手别人的工作 

            因为使用J-Hi开发，生成的代码与文件的风格都是相同的，在哪里写业务逻辑应该怎么写?在哪里要改页面应该怎么做?想要到哪张数据库表或表与类的对应关系?包括生成的类、JSP文件、配置文件的命名规则都是统一的。因此一个新人加入团队会很容易的上手并进入工作状态，即使是修改别人写过的代码，也会很快速的定位到相应要修改的位置。 

            9、快速解决需求变更 

            对于项目开发来说，项目的需求变更是很正常的事情，对于有经验的项目经理来说，如果一个项目从未发生过需求变更过反而是不正常了:)一但需求变更大多都要改数据库表，如果是已运行很稳定的系统，这种变更真是要命。J-Hi为此也提供了自己的解决方案，对于简单表变更，平台只要对单个实体生成就可以了。如果是复杂的变更，我们还提供继承实体的解决方案，也就是说原来的所有代码与表结构都不变，通过实体继承J-Hi会从数据库表到java类再到JSP页面形成一整套继承关系，从而保证以前功能的稳定性。这个说来好象很玄妙，让我们举例说明。比如你有一个部门表，N多信息都与它有联系，而且做了很多的业务处理，现在客户要求在部门表中加另一些信息。对你来说可能会为部门表中加字段，由此而带来所有类的变化与页面的变化，而这套系统已经很稳定已经用了一、两年了，开发人员都已经离开了公司，这样接手的人要读懂全部代码才有可能改，这样就造成开发速度的大大降低。平台提供了另一种解决方案:不动以前的任何东西，相关于在原有的基础上打上一块补丁。再做一张表，让这张表与部门表形成one to one的关系，而类无论是POJO、DAO、Service都继承自部门相应类作为父类，同时在JSP页面上也会继承所有部门的所有元素，这样就形成了实体继承关系，这就好比设计模式中最基本的“开闭原则”，对于所有的新生功能是开放的，而对于已有的老功能是关闭的，可以完全把老的功能视为一个黑箱。这样即能保证已有功能的稳定性，又能加入新的功能做为补充。  

            所谓平台:该怎么理解, 

            我觉得从广义上来讲，“平台”这个词应该是承载事物的环境或实体。比如我们说某某电子商务平台更多的体现在它的环境上，而当我们说观景平台时更多的体现在它是一个物理的实体上。不过无论是环境也好实体也罢，虽然在应用领域上会千差万别，但它们都有一个共同的特性，即平台是一个载体。让人或信息工作的更高效，从本质来看，好像平台更像是一种传统模式的有有益的补充，而非必须要有的。比如以电子商务平台为例，没有电子商务平台人们就不能交易了嘛?好像不是这样。我这样说并不是说平台是可有可无的东西，而是说有了平台会使人家更效、舒适的生活。反过来说，平台是对我们生活模式的有益补充。既然平台是一个承载体，所以理论来说它并不应该限制人们的习惯或方式，比如谁说观景平台就只能看风景，我在它上面吃饭不可以嘛?这当然是没有问题的(虽然这样做有些不合适，但没人会说这是不可以的)。 由上述对广义对平台的共同性特点来反观技术平台，好像在技术领域平台这个词很模糊java、net说自己是平台，还有一些以模型驱动的软件企业也说自己的产品是平台，在国内一些几个开源框架搭建起来带一些业务模型功能的也称自己是平台。对此我们应该简单的梳理一下:在技术领域好像平台是一个相对的概念，以java为例，java平台作为底层支撑着上述其它的平台。  

            在此我不想评价各个平台类产品的优劣，只是觉得国内的平台做得还不够好，这种不好不只是指技术还包括市场的运作模式、开放程序等方面。下面我说一下我梦想中的平台应该是个什么样子: 1、 平台应该是开源的，既然是平台就应该有一个开放的心态，这样才能使更多的人在平台上去开发相应的产品，才会有更多的用户群。像java语言为什么会远远多于其它语言的使用者，其主要原因就是它开源，开放标准，从而在框架类产品中形成百家争鸣的盛况，并且这种趋势并没减退还在继续——即使Oracle收购了Sun。由此我们可以看出一个开放性的平台，用户群足够多、技术足够公开，那么它的发展方向并不是由一家或几家大公司可以掌控的，平台的开放性将是一种趋势。 

            2、 平台应该是高效的，平台的最终目的就是提高生产力降低成本。首先从技术角度分析，它要足够的快速，从而降低开发成本;它要足够的简单易用，从而降低学习成本;它要适应已有的开发习惯与管理方式，从而降低风险成本;它要有足够的抽象性与复用性(即使是以平台开发出的产品也是一样)，从而降低重复劳动。其次，提高生产力降低成本是一个综合性的问题。平台应该不只是一个开发工具，应该是对应项目全生命期过程建立起自己的思想体系与解决方案，从而在整个项目周期内的每个环节都体现出它作用。例如从项目立项开始应该大体分为签定合同à需求调研à概要设计à详细设计à开发à测试à部署上线 (发布)à需求变更等，好的平台应该是对项目的全过程进行管理，例如现在项目开发存在一个很大的问题就是文档与代码不同步;再如测试用例与测试的覆盖率很低甚至没有测试代码或测试文档;再再如目前大多平台都没有整合打包的部署

            工具(跨操作系统、跨数据库、跨应用服务器)，一键式远程部署;最后需求的变更也是头痛的问题，平台是如何适应不断的需求变化的，大多平台均没有合理的解决方案。因此可以看出，平台是一个综合性的工程，仅解决一、两个点上的问题是不足以从根本上提高生产力降低成本的。 3、 平台的技术是可选择的，我们前面说过平台它只是个载体，至于在这个载体上放些什么，怎么去搭配使用，平台应该为使用者提供各种可选择的权力，甚至是可扩展、可插拔的条件。每个使用者都有自己各自的技术倾向性，这种倾向性有可能是他对某种技术的熟练程度，或者是出去于具体业务所采用技术的适应性。总之平台应该适应这种倾向性，它不应该拘泥于某种技术或某个框架，把这些选择权开放给使用者，使自己成为一个容器或是一个载体这才是平台最应关注的东西。 

            4、 平台之上的平台，从本质来看平台还是个实体是个工具，是人与机器的交流，而非人与人的交流。我觉得好的平台除了人与机器的交流外，更应该是一个社区一个人与人交流的平台，这样大家可以在这个平台实现资源共享，分享劳动成果。只有形成一个开放的生态社区或生态环境，大多数人都能融入其中，大家可以在这样平台之上的平台上共同工作，从而实现双赢，使每个付出的人都有收益。 

            浅谈J-Hi的理论基础 

            趋势 

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

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

            Java就好比是硬件的二极管，是所实现所有事情的根源与基础，而目前各各主流框架(如Struts、hibernate、ibatis、webwork、Spring等)都是站足在某个技术点上对Java功能的二次集成与功能扩展，这就象硬件中的集成电路，即本身是自封闭的各电路之间的通讯与融合还需另外元器件桥接。各主流框架也是一样它们只关注于各自技术领域本身，而不提供任何业务模型，框架与框架之间的集成工作也要手动配置。在谈业务开发平台之前说一下SOA，应用企业随着业务系统的增加，各系统之间的互通已是主要问题，而SOA就象internet让各应用系统间不成为信息孤岛。而J-Hi平台本身就定位在“大规模集成”这一环节上，虽然在业务开发平台这个环节中也有很多相关的产品，但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平台为开发的标准化提供了一个基础，原因在于代码生成无论是代码样式、风格及配置文件的规则完全相同。这样就保证无论人员如何流动这套标准是不会变化的。 

            剖析J-Hi对组件化的理解 

            按照《计算机百科全书》给组件的定义:是软件系统中具有相对独立功能、接口由契约指定、和语境有明显依赖关系、可独立部署、可组装的软件实体。由此定义我们来谈一下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，我们也会再提供更多的页面端的生成模版，以此类推，平台的技术组件会在技术的不同层面进行扩展。但与其它的技术组件不同之处在于，实现类似于插件一样的可插拔，随需织入。 

            对“J-Hi”Java快速开发平台问题的答疑解惑 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不只是一个开发工具，更是一个开放的生态社区，希望大家都能融入进来，也许前期我们会有一些投入，但我们的目的是想让更多的人加入到这个社区中来，大家共同工作，从而实现双赢，使每个付出的人都有收益。 

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

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