MyException - 我的异常网
当前位置:我的异常网» Java Web开发 » 再发贴,寻求ssh架构策略解决方案

再发贴,寻求ssh架构策略解决方案

www.MyException.Cn  网友分享于:2013-01-04  浏览:62次
再发贴,寻求ssh架构策略
现在网上流传的很多ssh架构的系统,包括开源的一些应用系统,很多都用了openSessionInView模式,这样一来,整个编程过程将大大简化。session的生命周期在整个请求范围内有效。我们可以把dao查询出来的有延迟加载属性的对象传递到页面中去。
但是在页面输出内容多的情况下,filter会使用页面缓冲区,这时filter的执行时间就和用户的网速有关,因此openSessionInview有可能造成数据库连接不能及时释放的问题。

如果不使用openSessionInView,那么我们一般会配置service层的方法使用事务,也就是说我们要在service层将所有延迟加载的属性
都取出来,放到vo中去,这样我们就需要建一系列的vo对象。严格的说,我们要在service层实现vo和po的转换。

保存数据时
action :获取formbean,将formbean转换为vo,save(vo)
service: vo->po,dao.save(po) (service层的curd方法都需要用vo做参数?)

查询数据时
dao:getList()
servce:遍历list,将list的每一个po转换为vo,有时需要处理po中的明细属性
这样vo和po的转换将带来很多额外的工作。有时感觉很多余。

另外有人提出用formbean作为vo,但是formbean是struts的东西,这样vo就和struts耦合,感觉不合理,最重要的是formbean反应的是form提交时的属性,但是查询列表里的对象可能和他的属性并不一样,除非构造一个冗余的formbean来处理输入和输出。vo和form的关系

这些问题,期望有高人可以解答。

------解决方案--------------------
延迟加载是罪魁祸首,所谓“成也萧何,败也萧何”。

我有时发现查询速度很慢,检查才发现是我没有启用延迟加载,造成递归的数据都被加载进来了。

我如果加上了延迟加载,那么许多页面将无法使用,必须在程序里进行递归的延迟加载数据的读取。

这里面涉及到的策略太麻烦了。

对于关联少,层次低的,用着没问题,一旦层次太多了,我宁可放弃面向对象,改用单纯的一个表,一个对象的策略,都保存字段就行了。

需要别的关联的数据,我宁可再次读取,毕竟有缓冲,速度影响不是很大的。而且单表的缓冲,性能绝对好。

能出现的问题就是某些显示时的一致性问题,但只要后台操作不出现一致性,前台我想偶尔出现没啥问题。


------解决方案--------------------
struts1的formbean继承了ActionForm类,与struts框架及其容器耦合,所以不能被用做po

不过struts1有两种方式能解决这个问题
1 声明一个对象,然后在formbean中引入这个对象
2 使用struts1的动态form,引入一个外部对象

这个对象,可以是vo、po,因为他是pojo,呵呵

以上两种都是最常用的方法。
------解决方案--------------------
使用VO的前提是你确认他对你的确有用(不仅仅是效率) 从PO到VO的转换 让VO更适合将信息显示给用户看(我们总不能在显示该用户性别的时候 显示 '1' 吧。。 )

但是加了VO之后回大幅度的增加代码量 所以像我这样的菜菜做的菜菜网站基本上是不需要VO的(也就是说你所做的东西如果太小的话则完全没有必要用VO)

FORMBEAN的存在价值只是用来封装用户提交上来的表单 不过我可以提一个建议(我菜菜 随便一说) 让SERVICE接受FORMBEAN来进行操作 减少 ACTION的代码量 然后SERVICE返回给ACTION的时候返回VO的集合...(不想误导楼猪 我也在等高人..) :)


至于STRUTS2 那完全是另一种模式(MVC2?) 不在讨论范围之内 我用了一段时间STRUTS2 感觉很方便 不过总感觉少了验证的一部分(对JAVABEAN的值进行验证 如果用了STRUTS2的话 我们接受到的直接是一个已经封装好值的JAVABEAN 当然 前台已经通过JS验证了啊 这时候我再进行验证的话 就感觉不太舒服了。。我目前的做法是直接把提交过来放好值的JAVABEAN扔给SERVICE 让SERVICE去检查JAVABEAN的值 然后再进行JAVABEAN转PO的工作)



自己写的好乱 不知道对楼猪有木有帮助 帮顶
------解决方案--------------------
opensessioninview就是为了解决延迟加载session关闭的问题,
将session的关闭一直延迟到表示层

如果想解决这个问题,LZ的方案虽然可行,但是会造成非常大的代码量和vo转换的耗费的时间
还有一种,就是尽量不用关系连接,不用延迟加载,不过这样也会造成性能问题

所以,没有一种方案是最优的
如果不是对网速要求非常苛刻,建议还是用opensessioninview的好
如果性能问题跟不上,那就不要用hibernate的好,换别的orm可能更好一点
归根结底,选合适的就好

------解决方案--------------------
探讨
其实主要问题还是出在延迟加载,
如果不用延迟加载,同时又设定了关联关系,那么很多时候会做不必要的关联查询
如果用了延迟加载,又不用openSessioninView,则必须在service层去将需要使用的延迟加载的属性都取一遍

文章评论

软件开发程序错误异常ExceptionCopyright © 2009-2015 MyException 版权所有