Hi平台指南Word文档格式.docx
- 文档编号:1004887
- 上传时间:2023-04-30
- 格式:DOCX
- 页数:106
- 大小:1.20MB
Hi平台指南Word文档格式.docx
《Hi平台指南Word文档格式.docx》由会员分享,可在线阅读,更多相关《Hi平台指南Word文档格式.docx(106页珍藏版)》请在冰点文库上搜索。
6.1接口36
6.2配置信息37
6.3生成的相关内容37
第7章表现层38
7.1接口38
7.2Webwork实现39
7.3标签41
7.4JavaScriptJSON定义45
第8章通用API46
8.1树型结构46
8.2Java脚本工具48
8.3常用工具类48
第9章通用应用服务49
9.1权限管理49
9.2组织结构56
9.3枚举管理58
9.4任务管理58
9.5菜单树型结构的应用与实现59
9.6国际化(i18n)应用与实现63
第10章开发规范64
10.1开发约定64
10.2关键字、保留字列表65
第11章相关资料附录65
11.1C3P0连接池配置描述65
11.2Acgei与配置文件相关的类说明66
11.3Quartz中Trigger的时间间隔设置69
1
前言
在当今的企业级开发过程中随着开源框架的不断成熟(稳定性与可维护性已不是问题),如何快速提高开发效率,降低开发成本已成为急待解决的问题。
而软件行业正在走着一条硬件的老路,功能[二极管]集成[集成电路]大规模集成[大规模集成电路]网络[internet],上述路线对应java世界的软件实现J2SE/J2EE[功能]在表现层/业务层/持久层的框架[集成]平台[大规模集成]SOA[网络]。
Hi平台本身就定位在“大规模集成”这一环节上,目的是将主流的框架集成由该平台当中,为您呈显一个高效、稳定、可复用、低耦合、通用化并且功能齐全、用户体验友好的套件产品。
同时平台也是一个了解主流开源框架很好的学习工具,因为平台本身是一个设计良好开放的框架,除了支持目前主流的w(webwork)或s(struts)s(srping)h(hibernate)开发模式,您还可以通过扩展平台实现其它非主流的开发模式,如页面你可是vm/ftl/pdf,在持久层上您可以采用JDO等。
并且所有文档及代码注释均采用中文,为您快速了解平台及相关java框架提拱一条便捷有效的学习途径。
可以说本平台是团队成员多年做企业级应用开发经验的总结,提供大量通用的API与通用业务功能,因此平台的价值不仅仅在代码生成上能为您提高开发效率,而且在业务实现上也会使您的开发大大加快。
就平台本身来说,可以大体分为三个部分:
1)生成器:
通过eclipse插件使您可以通过可视化的方式设置符合您业务需求的服务与实体,并且会自动生成从页面一直到持久层所有文件(包括配置文件)、java代码及sql脚本。
通过生成器的生成,可以实现CURD的所有基本功能(从页面直到数据库表),为您呈现一个可运行,可操作的所有功能。
2)支撑系统:
平台在java代码与js提供了一套完整的面向对象的支撑系统,您可以认为这是一个抽象层,无论是在页面表现上,还是在CURD的任意一层,平台均提供了最大限度的抽象。
用以保证平台本身的可扩展性、稳定性及灵活性。
也是在本系统中提供了大量的API(java与js),为您在开发过程中随需调用,从而进一步加快开发速度,保证代码质量。
3)通用应用服务:
这是平台为您提供一整套相互独立而又彼此依赖的组件化服务,其中包括组织管理、权限管理、菜单管理、枚举管理、任务管理、应用配置管理、委托管理、发送管理、树型组件等等。
其目的是根据团队大量的开发经验,将企业级应用所必须的且与业务需求关系不密切的功能性服务抽象出来,形成按需配置随处可用的通用应用服务,进而使您的开发在业务层面上的开发速度也会有所提高。
综上所述,平台在三个方面来提高开发效率,首先,是生成可以使谁从枯燥的复重劳动解放出来使您将精力更多的用于把握客户的业务需求;
其次,平台提供了大量的统用API与工具类,从而进一步加快开发进度提高代码质量;
再次,平台本身包含一些通用且自身完成,高扩展性的业务组件,为做好一套应用前期就打下一个坚实的业务需求基础。
如权限、菜单、任务管理等等这些常用的功能,如果你选用的本平台在您的开发计划中均不会有对这部分功能的开发记录,从而使您业务层面上也可以提高开发效率。
平台的开放性也注定了它会不断的容入进的元素,加入新的框架。
不断的求新、求变、保证性能的稳定与功能的完善是它追求的目标。
嗨!
~~,象打个招呼这般简单实用是它的源动力。
最后,平台是一个开源项目也是一个开放的系统,您可以根据您的需求任意配置、扩展,但扩展平台的功能所带来的风险本团队不予承担。
在学习平台的过程需要您对Spring有些了解,知道目前的一些开源框架(如hibernate、webwork…)。
当然您也不要为必须了解这么多框架所吓倒,因为平台生成器会提供所有这些框架的实现样本代码,您可以分析、修改生成的代码与配置文件进而实现您的业务功能。
由此可见平台不但是一个开发工具也是一个设计良好的学习工具。
第1章系统结构
上图是在功能上对Hi平台的高度概括。
通过该图可以看出平台采用JavaEE接合Spring实现从数据库端直到业务端的全线贯通。
从总的技术路线来看平台充分发恢SpringIOC与AOP的强大功能,实现业务层两端(即表现层与持久层)的完全解藕与无缝集成。
在此要强调这种集成并非传统意义上的提供一套简单的配置文件,而是结合业务对每个框架的集成均提供一套更符合业务、调用更友好的抽象层,抽象层除封装、集成外还提供一套客户可配置,扩展性良好的通用API。
而对于颗粒较大的功能项,我们以通用组件的形式发布于平台之中,如树的展示、对象化的树型结构等等。
在页面表现上平台除提供可客户化扩展的标签库外,还为您提供一整套以ajax技术为核心的富客户端,从而使用户感受更好,更象是web2.0技术实现。
除此之外,平台更加靠进业务提供了一些通用的应用服务,包括权限管理、组织结构、任务管理等等,对于通用的应用服务我们以后的版本中不断加入,可以看出平台是一个开放的不断扩充的集成开发工具。
最后,生成器贯穿于所有层面,可以生成任何层面的文件与代码。
第2章快速上手
2.1举例说明
实体关系图:
员工表(staff)包含员工个人信息,婚姻状态、工作状态、学历为枚举类型,与经历表(Experience)的关系为一对多关系。
民族(Nation)、工作岗位(JobPosition)为查找带回类型。
首先找到HiStudio目录:
HiStudio工具主页面:
如果没有HI项目视图:
HiStudio工具,打开HI项目视图(窗口->
显示视图->
其他->
Hi集成开发平台->
HI项目视图)。
点击“创建Hi工程”按钮
点击“设置数据库连接”按钮,设置数据库连接的相关属性:
设置数据库连接之后,
成功建立Hi工程
右击HI项目视图->
test
点击“实体”按钮,编辑员工(staff)、经历(experience)、民族(nation)、岗位(jobPosition)等实体。
点击“枚举”按钮,编辑员工婚姻状况、工作状况、学历等枚举类型值。
点击“引言”按钮,建立员工与经历表的一对多关系。
启动TOMCAT后,在浏览器中运行以下地址:
http:
//localhost:
8080/test/
test为你的工程名称
用户名、密码都为sa
进入编辑页面对实体进行“增删改查“操作:
第3章生成器
3.1生成器环境目录
所谓环境目录是指生成器在生成过程中所依赖的目录体系,缺省生成器会按这套目录录体系取查找配置文件与模版文件。
缺省该目录下会有如图的子目录
✓config目录:
存储当前开发的服务(*.hsc.xml)文件及environment.xml(环境配置)文件。
环境配置文件:
主要的功能是配置生成器的系统配置,如数据库链接、模版文件的位置、生成后的输出文件的位置等信息。
注意:
环境配置文件(environment.xml)必须放在APP_HOME/generater/config目录下
服务配置文件:
每个服务均有一个服务配置文件,您可以认为一个服务就是一个业务功能模块模块(如库存管理、资产管理…)。
推荐在服务内代码间是高内聚的,因为一个服务就是一套完整的业务,在设计服务时应尽最大限度的降低服务与服务之间的藕合度。
服务配置文件的主要功能是生成服务内所有实现的代码与文件
✓generated目录:
为生成器生成的标准文件存放地址。
可以通过在环境配置中设置“标准输出”改变其缺省值
✓sechemas目录:
系统保留目录,用于存放所有xml文件的sechema描述(*.xsd)文件
✓temp目录:
系统保留目录,由于生成的过程是先生成ant的build.xml文件,再调用ant由该文件生成其它文件(java代码、JSP、SQL脚本、资源属性、权限配置、hbm、Spring配置文件…)。
该目录是生成的中间过程要存储的相关文件,生成结束后该目录的所有过程文件将被全部删除
✓templates目录:
生成器所依赖的生成模板存放地址。
可以通过在环境配置中设置“模板目录”改变其缺省值
3.2生成器生成原理
在了解生成器生成原理之前,首先要清楚什么是实体?
实体与实体间的关系?
✓实体:
一个实体您可以理解成与数据库对应的一张表,实体之间可以继承、一个实体可以有多个子实体。
但实体不仅仅是数据库表,它包括从页面到数据库表之间的全部代码实现同时包括CURD所有操作的功能单元。
✓实体与实体间有如下三种关系:
●主从关系:
又作Head-Detail(头-明细),例如入库单与入库单的明细,这是两个实体而他们之间是主从关系。
也就是one-to-many
●继承关系:
这种继承是从数据库表一直到业务层,全部继承的实现。
也就是说在类与类之间是继承关系,而表与表之间是one-to-one
●Lookup关系:
是一个实体对另一个实体的依赖,比如在部门(一个实体)中有一个部门经理(另一个人员实体),即部门对人员实体的依赖。
对于部门的POJO来说是一个domainObject,而对于表关系是many-to-one
生成器生成的过程也就是Ant执行build.xml文件脚本的过程,让我们分析一下该文件的主要元素
ANTbuild.xml文件元素描述
org.hi.generator.ant.HiGeneraterToolTask类是ant生成器调用的主入口,通过
<
taskdefname="
generatertool"
classname="
org.hi.generator.ant.HiGeneraterToolTask"
classpathref="
tasks.classpath"
>
/taskdef>
配置做一个ant任务的映射,然后再配置任务
targetname="
generateing"
<
generatertoolenvdir="
${environmentdir}"
destdir="
D:
/RFID/workspace/generater/generater/generated"
>
<
environment/>
serviceentities="
"
filesetdir="
${environmentdir}/temp"
casesensitive="
yes"
<
includename="
**/*.hsc.xml"
/>
/fileset>
/service>
genddl/>
genjavadestdir="
/RFID/workspace/cubby/src"
/>
genormdestdir="
gensecuritydestdir="
genseeddata/>
gencontextdestdir="
genviewconfigdestdir="
configExtends="
cubby"
genpage/>
/generatertool>
/target>
generatertool元素:
引用的是上面的任务映射,是生成的主调用入口。
envdir属性:
指定生成器环境所在的目录,一般为/PRO_HOME/generater目录
destdir属性:
指定生成的文件存放顶级目录,一般为/PRO_HOME/generater/genrated目录,如果子元素没有覆盖该属性,则生成出的文件会自动存到这个目录的相应位置
environment元素:
目的是加载环境配置文件
environmentFile属性:
指定环境配置文件存放的位置,如果为空,则系统会自动通过generatertool元素的envdir属性所指定的环境目录的指定位置取得环境配置文件
service元素:
加载要生成的服务配置文件,注意加载的位置为envdir属性所指定的下一级temp目录,如/PRO_HOME/generater/temp中的所有*.hsc.xml文件
entities属性:
可以指定在给定服务下的仅生成某几个实体,属性的值用逗号(,)分隔,属性的值为空串或没有该属性则视为服务下的全部实体均生成
genddl元素:
生成DDL数据库脚本文件,脚本文件的类型是由环境配置文件dbtype元素指定的
genjava元素:
生成所有java源代码,包括POJO/DAO/Manager/Action
ormType属性:
ORM的类型,缺省为hiberante
viewType属性:
View层框架的类型,缺省为webwork
gensecurity元素:
生成权限配置文件,命名规则为服务名-security.properties
genseeddata元素:
生成数据库的种子数据的SQL脚本,包括三部分容菜单、权限与枚举信息
gencontext元素:
生成Spring的配置文件,命名规则为appContext-服务名.xml
genviewconfig元素:
生成View层框架配置文件
pageType属性:
展示页面的类型,缺省为jsp
configExtends属性:
指生成的配置文件继承自基本配置文件的名字(包名)
genpage元素:
生成页面文件
viewType属性:
生成过程
通过ant的配置文件可以看出,平台定义了一个自己的任务映射org.hi.generator.ant.HiGeneraterToolTask,通过该任务平台首先加载环境配置文件,然后加载指定目录(默认为temp目录)下的*.hsc.xml服务配置文件。
最后按指定生成的元素生成相应的文件。
在生成过程中因为实体与实体之间有依赖也就是参见实体间关系,所以在生成时要加载所有的服务配置文件。
也就是说生成器除了加载要生成的配置文件外,还要再加一个全部的配置文件。
对于加载全部配置的规则为首先它会到config目录(这个目录下的全部配置文件是您的业务服务配置),然后它还会加载系统自身的配置文件,位置在org.hi.generator.context包下。
手动生成的操作步骤
生成器环境的目录参见环境一节的描述
1、根据需求配置config目录下的environment.xml,配置好后将其拷贝至temp目录中
2、根据需求手动编写服务配置文件(*.hcs.xml)并存放于config中
3、在temp目录下修改build.xml文件
4、将要生成的服务配置文件拷贝到temp中
5、运行ant
6、执行数据库脚本服务名.sql与服务名_BaseData.sql(可选)
7、将生成的JSP文件拷贝到web目录下(可选)
3.3配置配置文件
数据库设置:
与数据库连接相关的配置项
✓URL:
JDBC规范的数据库定位,如jdbc:
jtds:
sqlserver:
1433/HiTest,jdbc:
<
数据库驱动的类型>
:
//address:
port/databaseName
✓Driver:
JDBC的数据库驱动程序
✓Username:
数据库的帐号
✓Password:
数据库密码
✓数据库类型:
所连接数据库的数据库类型
MSSQL
SQLServer2000(或更高)+sp4
MYSQL
MySQL5
ORACLE
Oracle9i
Java设置:
生成器所依赖的java配置
✓JavaHome:
生成器所用java虚拟机所在的位置
✓jar包目录:
生成器所依赖jar包存放位置
生成设置:
与生成器生成过程与生成结果相关的设置
✓组织包名:
生成java源代码所在的根包的包名,一般情况下应该写为panyname,companyname为公司英文名全部小写
✓模板目录:
生成器所依赖的生成模板存放地址的根目录,缺省为APP_HOME/generater/templates
✓源代码输出:
生成器所有生成的源代码存放地址的根目录,一般情况应将该目录设置为APP_HOME/src。
在此要注意这里的源代码不仅只包括*.java文件,源代码的文件类型主要有:
●*.javajava源文件,在框架层次上主要有POJO/DAO/Manager/Action及枚举常量类
●*.hbm.xmlhiberante的ORMapping文件,注意:
目前仅生成hibernate的Mapping文件
●*-security.properties权限管理的属性配置文件
✓标准输出:
指除源代码输出外其它自动生成的文件的存放地址的根目录,缺省为APP_HOME/generater/generated。
生成文件的类型、内容及各级子目录的含义参见后续章节
3.4服务配置文件
3.5生成文件描述
由生成器生成的文件主要分为四类:
✓Java代码:
Java代码按技术层面上又分四类:
◆表现层,与表现层相关的代码放在action包中,又因所系统所采用的表现层框架不同会有相应的子包,如果您的表现层框架是用的webwork则生成器会自己生成action.webwork子包,同意如果用的是struts则生成action.struts子包,也就是说表现层框架的差异会生成不同的子包。
所有的Action类均放在相应的子包下。
对于Action类生成器会对每个实体生成相应操作的五个类***ListAction(查询)、***RemoveAction(删除单条记录)、***RemoveAllAction(删除选中的记录)、***SaveAction(保存)、***ViewAction(查看)
◆业务层,与业务层相关的代码放在service包中。
对应每个实体都会生成一个接口与一个具体类,分别在service包impl包下。
◆持久层,与持久层相关的代码放在dao包中,每个实体都会生成与之对应的***DAO接口,对于不同的持久层框架会生成不同的子包,比如hibernate,就会生成dao.hibernate包,***DAOHibernate类实现***DAO接口
◆实体模型,与实体模型相关的代码放在model包中。
在该包中分为抽象类(***Abstract,在original包下)与具体类(***,在model包下),之所以这样分开的原因是生成会反复生成覆盖抽象类而不会影响您手改的具体中的代码
✓配置文件:
按配置文件类型分为四部分
◆权限配置文件(***-security.properties)放在相应服务的根包下,目的是实现表现层与业务层的权限处理
◆表现层配置文件(xwork[根据采用表现层框架不同该名称会有差异]-***.xml)放在src根包下,目的是实在表现层的配置如webwork的配置
◆业务配置文件(appContext-***.xml)放在相应服务的根包下,目的是完成Spring的配置
◆持久层配置文件(***.hbm[根据采用的持久层框架不同该名称会有差异].xml)放在相应服务的model包下,目的是实在持久层的配置如hibernate的配置
✓页面文件:
页面文件分为jsp与js文件,对应每个服务缺省放在APP_HOME/generater/generated目录下
◆jsp文件:
对应每个实体(枚举实体除外)均会生成三个jsp文件用于展示,***Edit(编辑与保存页面)、***List(列表与查询页面)、***View(查看只读页面)
◆js文件:
对应每个实体(枚举实体除外)均会生成一个***.js文件,用于javascript客户端的调用
✓数据库脚本文件:
对应每个服务均会生成两个数据库脚本文件,用于生成数据库表与为系统表插入数据,缺省放在APP_HOME/generater/generate/db/(相应数据库类型)目录下
◆DDL文件:
***[服务名].sql,定义该服务下所有实体(枚举实体除外)的数据库表的创建
◆SQL文件:
***[服务名]BaseData.sql,用于对该服务下的实体为系统表插入相关数据,系统表包括:
菜单、权限、枚举…
3.6生成器所带来的新规则
如果您采用本平台开发,理论上80%以上的代码都是生成出来的。
这样就带来了一个新问题—如何保证我手动改写或添加的代码不会被生成器生成的文件所覆盖?
考虑到上述问题生成器在生成文件时有如下规则:
生成器会反复生成并覆盖以下类与文件:
i.model.original包下的抽象类
ii.action包下***PageInfo类
iii.model包下的***.hbm.xml文件
iv.服务根包下的appContext-***.xml文件
v.服务根包下的***-security.properties文件
vi.src根下的xwork-***.xml文件
除上述文件外,生成器对生成其它文件时均会判断是否以存在,如果存生就不再生成也不会覆盖已生成或手动修改类或配置文件的内容
从反复生成的文件规则上可以看出,生成器只会反复生成:
1)
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- Hi 平台 指南