Jalor 5学习心得

时间:2021-03-16 12:57:16

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(