再发贴，寻求ssh架构策略解决方案
日期：2014-05-18 浏览次数：20642 次
再发贴，寻求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可能更好一点
归根结底，选合适的就好
------解决方案--------------------
现在网上流传的很多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可能更好一点
归根结底，选合适的就好
------解决方案--------------------
免责声明： 本文仅代表作者个人观点，与爱易网无关。其原创性以及文中陈述文字和内容未经本站证实，对本文以及其中全部或者部分内容、文字的真实性、完整性、及时性本站不作任何保证或承诺，请读者仅作参考，并请自行核实相关内容。
