如题,高手详细点说一下,谢谢了
解决方案 »
- 马士兵老师JAVAEE struts2视频项目源代码
- TransactionFactory class not found: net.sf.hibernate.transaction.JDBCTransaction
- 关于IE6链接标签href="javascript:void"不能提交表单的问题。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。
- 急!高分请教!spring security的url匹配的相关问题!
- Hibernate 注解Blob字段
- hibernate 的多事务回滚
- 帮忙解决一道编程题
- sf
- MVC之Struts问题 - 在线等待
- java JDK动态代理和cjlib动态代理里的invoke 方法的疑惑
- struts2的action设计原则
- eclipse SVN 改文件名字
而VO(value object 值对象) 通常用于业务层之间的数据传递,在WEB应用中,一般用于和前台页面做数据相互。
Struts1.x被2.x代替后VO层消失了,在action中直接传递PO,这样代码显得很简洁,很多SSH应用也都这样做。简单应用完全可以省VO而之久用PO,但还是建议使用VO。原因如下。
在目前的SSH中,若符合JPA规范,那就先设计PO model,再生成数据库。
在struts 2.1.6中使用json格式作为输出,PO对象中包含着复杂的关系,如果又是双向的,很容易出错,为了避免错误,我们又要在PO中打上相应的忽略注解,框架一多,各种注解参杂在PO中,显得很乱,最后都搞不清这些注解到底代表哪个功能。
若使用VO,原先PO中存在的一些字段也可以放入到VO中,PO可完全对应于数据库字段,而把一些需要和前台交互的字段放入VO中,VO中尽量存放简单数据类型。
这样不管是前台使用什么系统(webservice和doNet C#交互,还是使用flex,ajax json等),转换为xml格式也异常简单,制作报表也不用过多的考虑如何解析传递过来的复杂对象和子表嵌套。用户关系的只是workType.name而不是WorkType这个类,VO由业务层产生,传递给视图层或其它各种接口。这样可以使得层次间进一步解耦,PO对象模型也变得容易维护(少了很多注解,代码清晰)。也使得前端数据结构的变得更轻(VO都是简单数据类型),有利于传输和解析。有点长。好好体会一下吧。