gaojingsong 阅读(936) 评论(0)

一、简介

技术都是相通的,jalor5框架的核心思想是CXF Restful + Spring3 + Mybatis +自定义的界面实现,使用jquery EasyUI也可以实现类似的界面效果,因此掌握Spring相关技术和Mybatis技术就可以胜任jalor5技术

 

二、jalor5学习心得

 

备注:这篇心得转抄摘自网上,附件是摘自网上的一篇文档,解压密码QQ:525354786.如果违反作者禁止传播思想,烦请作者联系我进行删除.
  jalor5是一套功能强大的框架,该框架集成了spring、mybatis、cxf、日志、异常等组件,和其它未提及的部分组件,如消息组件。
它还自带了权限管理,内容管理,国际化等功能,该框架在项目开发中起到了缩短项目周期和降低技术难度的功能。
  虽然jalor5的开发和使用都有大量文档,但是我觉得一个从未接触过jalor5甚至未接触过Spring框架的人来说,单单靠jalor5的文档,
还是会遇到很多的问题,比如环境搭建,数据流的方向等。jalor5是在jdk1.5的环境下开发的,文档中说使用其它的jdk版本或许会存在问题,
但是如果用jdk1.5的话jalor5会有错误,而且在新建项目中也存在一些细节与文档上的差别,文档中的部分例子不够全面,使得在学习过程中
遇到了很多小的但是又难以解决的问题。就算环境搭建都没问题了,在建好项目了之后也会遇到个别的问题,比如数据库的初始化、包名的固定
命名、请求url的写法,各个应用层代表的意思,接口层中path注解的命名都会遇到各种不同的问题。下面我说说我遇到的问题和解决方法:
  问题(仅是我遇到的,大家使用的时候不一定会遇到):
   1、lib包的编译问题,刚开始的时候提示编译版本不对,要使用jdk1.5版本编译。解决方法:按照提示改成jdk1.5编译即可(改了之
    后再切换回jdk1.6错误不提示了,很是奇怪)。
   2、数据库初始化问题。jalor5的使用必须初始化数据库,而oracle的安装和导入数据脚本是必要的,但是导入脚本过程中也要注意
    修改脚本中的appname和scope的名字,我是只改了appname为自己的应用程序名即可。因为jalor5的后台管理菜单的内容是
    根据appname去获取的,所以这一步是必须的。
   3、新建项目中包的命名,我自己随便命名,结果程序一直报错。解决方法很简单,修改包名为com.huawei.it打头即可,当然相应的
    层命名必须包含有dao、service等全小写的单词,因为spring配置是要去扫描这些配置的路径的。
    比如service的包命名:com.huawei.it.yq.report.service   其中yq是应用程序名、report是模块名、service代表服务层。
   4、api接口层、impl实现层、test测试层、test测试支持层(test.support)、web层的概念:
    api接口层:在这一层中全部放置接口类,接口类包括dao数据库打交道层的接口、service服务逻辑层的接口;还放数据库表
     对应的java类对象,即vo对象。该层的service接口需配置@Path注解和@Produces注解。
    impl实现层:依赖api层,在这一层中全部放置api层接口的实现类和dao接口对应的映射xml文件(mybatis文件)。在service实现类中必须
     使用@Named注解。在service实现类中用到dao接口要使用@Inject注解。
    test测试层:依赖impl层、test测试支持层,使用junit4来编写测试类,测试service实现类是否可用可行。这样子不用每次都启动tomcat来测试。
    test测试支持层:该层只存放两个配置文件:xx.test.support.beans.xml、xx.test.support.configs.xml,需修改数据库连接代码等。
    web层:该层最重要的就是web.xml配置文件和application.xml文件,还有config文件下的几个配置文件。该层没有何人其它文件,
     它的存在只是为了加载我们的应用程序api和应用程序impl,tomcat启动的时候就会把api、impl层编译装载,它们就全部在一个web里面了。
   5、分页传递参数最好以对象的形式去传递参数。
   6、vo、dao、dao的映射xml文件的自动生成,在路径中选择api层中的src/main/java路径,包名必须以com.huawei.it打头。
   7、html页面、js文件的代码编写。css文件的引用。
   8、国际化信息管理,当添加国际化信息后,需要清空缓存才能显示,这点要注意
  而我在这两周的时间学习了jalor5的一些功能,主要是我们当前项目需要用到的,主要知识点有:
   1、IGrid表格的数据显示,数据来自oracle数据库。
   2、IGrid中实现数据的批量添加、修改、删除。
   3、IGrid实现过滤功能,有降序、升序,过滤条件有等于、大于、包含等,单选按钮、多选框选择过滤等。
   4、from表单的数据显示、修改、增加记录的实现。
   5、表单主要用到文本框控件、单选按钮多选按钮控件、时间控件、下拉选择控件等。
  对jalor的数据流方向有了一定的了解,知道模块开发的流程、功能的开发流程,从项目的搭建、数据库的连接、前后台的数据交互都有了一定的了解,我知道jalor5的很多
知识都还需要学习,但是我觉得不需要全部都精通jalor5再去做项目,没有必要。其它的知识点可以在需要的时候再去学习,这样可以一边做项目一边熟悉,再不懂的可以请求jalor5
Jalor3 中沿用的古老的七层Pattern架构,产生了大量吃闲饭的冗余代码,想必很多人都深有体会,恨之入骨。我们可不敢站在人民的对立面,于是我们决定精简代码层次,推出Jalor5框架,来解决大家的心头大家知道的,Jalor5 最终采用 展现层/服务层/数据访问层/数据库层的精简4层结构,不过这个四层架构的来历也并不简单。刚开始的时候,我们团队内部对新的架构存在一些分歧,部分团队成员坚持认为应该在展现层和服务层中间增加服务Facade层,理由是便于在这一层上进行权限控制和服务暴露,如果没有这一层,由于服务层之间的相互调用,权限将在一个网状结构中传递,众所周知,网状结构是难于控制的
           
举的例子:A服务,调用了B服务和C服务来进行一个完整的操作,在没有服务Facade层的情况下:
1.        如果ABC三个服务都控制了权限,难道我们要给用户授予ABC三个权限,用户才能使用A服务?这显然是不可接受
2.        那我们换个方式:利用技术手段,只在A上控制权限,忽略BC的权限控制,有时候B操作是个关键操作,必须强制进行权限校验,也是不可接受
3.      如果A是个批量保存的操作,他调用批量更新的操作B和批量新增的服务C来完成任务,这时A不控制权限,而交由B和C分开控制,对于没有新增权限的人,如果提交的数据中只有更新数据的,这个操作仍然可以成功
4.     更复杂的情况,A服务是不控制权限的,B服务又调用了D服务,C服务又调用了E服务,或者交叉
显然问题的复杂性在一步一步上升。我们来做个比喻,你去一个大的景点玩(A服务),买了张门票,到里面的大部分景点(B、C)是不需要再买新的门票的,但是有一些特殊景点可能需要。有的大景点是免费的,里面的小景点(B、C)要分开买票。更复杂的情况是,大景点(A)是免费的,里面有两个收费的中型景点(B、C),中型景点里面又有小景点(D、E),这些小景点只认对应的中型景点的门票(D只认B门票,E只认C门票)
增加一个服务Facade层可以有效的解决这个权限的问题,权限仅在Facade层控制,也就不存在网状问题了。但是为了这少部分的权限场景,增加这一层吃闲饭的到底划不划算?我们可不敢再一次站在人民的对立面
我们徘徊在大中小景点门前,思绪如那团网状的乱麻,我们真的要接受这个一刀切的超级联票吗?我们真的要放弃心底对极致简约的追求吗
如果你看了标题,你就知道上面两个问题的答案是否定的。
有的时候我们走入了困境,总希望遇到可以指点迷津的大师。我时常梦见,大师拄着禅杖,道一声哦米拖佛,说施主你只需如此这般(此次省略411个字)便可。
其实,无论你指望,或者不指望,大师就在那里,也不曾走远,只是你看不见,也摸不着。EJB 的设计者中就有这样的大师。我们回想起 EJB 中的事务传播模型,发现 EJB 的事务就是在一个类似的网状结构中传播
参考前辈的方案,我们将每个服务对权限的控制策略分成了几种:Mandatory(强制校验)、Required(前面校验了我就不校验,否则校验)、IgnoreAll(忽略后继所有的权限校验) 等几个级别,并引入了栈、桢来管理传播关系,权限拦截器根据服务的权限控制策略来进行必要的控制,这个问题也就迎刃而解了。
以上述例4来说,其伪代码如下:
java代码
public void a(...){
    ...
    b();
    c();
    ...
}

@JalorOperation(policy=Required,code="..",desc="..")
public void b(...){
    d();
    ...
}

@JalorOperation(policy=Required,code="..",desc="..")
public void c(...){
    e();
    ...
}
@JalorOperation(policy=Required,code="..",desc="..")
public void d(...){
    ...
}
@JalorOperation(policy=Mandatory,code="..",desc="..")
public void e(...){
    ...
权限拦截器处理的示意图如下:
我们也就无怨无悔的去掉了服务Facade层,和人民站在了一起
以上问题只是 Jalor5 建设过程中遇到的无数问题中的一个,每一个问题,我们都全力以赴。我听到很多SE经常把“做不了”、“没办法”挂在嘴边,殊不知SE的职责就是解决问题。解决问题最重要的就是思路,没有思路时,问题是困难的,有了思路时,问题就简单了。不爱动脑子的SE不是好大厨,只要开动大脑、全力以赴、善于借鉴,办法总是有的。