结合struts和hibernate谈J2EE架构的数据表示

你的这种设计方式是很正确的，
但是我想进一步问，如何保证 3层中某一层的修改不会影响至其他层呢？
这能做到吗？
   比如我的数据结构改变了，需要在用户表中增加一个“头像”的属性
那我的业务层和显示层岂不是都要修改吗？而且在这几层之间的对象转换的代码
一样的需要修改，不是吗？

以上的兄弟们有些逻辑性的分歧

首先MVC是什么
V：视图
C：控制
M：模型

1。视图不是你们所说的看到的东西
（看到的是B/S中的B，是一个由Html代码组成的message没有一点jsp代码）
2。控制不是动作所以一定不是Action
（什么叫控制？控制就是老板，老板手下有N个员工，
一个活所有人都有几会去作，但是老板只让张三去作。
所以控制是由actionservlet+struts-config.xml组成的
actionservlet是老板而struts-config.xml是为什么用张三）
3。模型不是Formbean
（什么叫模型？模型就是真实世界在计算机中的影子，
项目中的用户，模型就是真实世界中的某个人，
他要使用系统，那么他就是login
他还要含有用户信息，名子，密码
含有用户信息的是模型？还是能login的是模型？
只有又含有信息又能动作的才是模型
FormBean中只是模型全部信息的一部分
Action只是一条通向动作的一个电话线
只有加上逻辑层后所有的东西才算的上
模型。。。。。。）


另三层架构是什么
application
service
dao
从前面可知这三个加起来才叫业务逻辑
由于业务逻辑复杂性
才把逻辑代码分成了三块。。。。。
（很早以前是都写在action中的
现在把多个action中的代码分出来
另外把相同的代码删去
再分为三层为了删去更多的冗余代码
）
application这东西大约就指调用这个模块的那一句话&之外的其它视图类的东东
如User.login(username,password);
dao数据层。。。。。把数据库的数据变成想要PO，主要是数据读与存
service就是所有的可变他性的东西都放在这里。。。。
如果service都没有什么区别的话。。。
把所有代码写action中去吧还少占一层。。。

1。很多人发现vo与po很像。。。。
如果一样的话那么还是看看设计是不是有问题
2。vo与po转化
eclipse的hibernate工具生成一个po之后让vo继承po
再之后如果还有就再继承一次注意不要把东西写的太杂乱了
不然吐血也看不清（吐了N次血了）
之后把vo组合进formBean中
（我的项目中用到的方法，<input name=user.name/> ）

抛出异常的爱。。。。。。实践所得运用可行

我最近也在做hibernate和ejb方面的设计，也碰到了vo和po的概念，这里我对vo和po的概念也感觉很不清楚，ejb层应该是业务逻辑层，那么vo应该是ejb容器层的对象，而po是DAO访问的数据层， 那么传递给web层的对象（我认为是DTO），该对象应该是VO吗？ 还是再根据VO抽取出DTO？
此外，VO和PO的区别究竟在哪里？ 真的很想参考以下别人的比较完美的设计，不知道有没有这样的开源的小一点的项目，但是又完美的体现了前面说的这些层的概念，可以借鉴借鉴就好了。

我也正在作这方面工作
ejb这边用的是PO
将po数据给DTO
DTO是传给Action中的
而页面上还是要用form
如果有list还要在form中加入list

(DTO:Data Transport Object 数据传输对象 )
(VO:Value Object 值对象 )
可以看出两个本是一个东西
只是DTO是没装数据之前的名子
但是安了值就叫VO
什么都可以叫VO只要它有值，
(hibernate 中专指非PO的类不能对数据库操作的类)
但是从数据层到显示层之前的传输对象一般叫DTO
其它的带逻辑动作的叫BO

。。。。。。。。。。。这个叫开闭原则么？
所有的代码都改了。。。。。。。。。。
一般新加一个头像的方法是这样的。。。
1建一个类是原来用户的子类（叫带头像的用户）
2XXXXX逻辑XXXXX
3写一个新页面带头像的再包含前面你写的页面
4调整代码。。。。。。。
以上方法复杂研究专用。。。

多谢答复.
我还是不清楚在使用hibernate设计系统时, 由于它的强大功能以及PO是轻量级的POJO, 似乎PO就可以直接作为DTO来传输出去, 但看了许多人的讨论,都说PO只是数据库层的实体对象, 并不应该直接作为DTO对象来传输, 按照这个说法, 理解上感觉可行,但可操作性上感觉很麻烦, 对于某些DTO并不完全是PO的情况, 转换成DTO对象还有意义,对于DTO完全就是PO的情况, 再做一个专门的DTO感觉有点多余, 有没有好的方法? 前面有人讲到在多数情况下PO等于VO(也就是我所认为的DTO)的情况下,可以使用反射的方式来避免繁杂的转换的体力劳动,我觉得可行, 可以尝试一下看看.

。。。。。你说的那种直传po的大多都是设计有很强冗余的表
而且可能是以数据库驱动开发的项目
这类项目可以考虑用代码生成器
而不是一点点手写代码
。。。。。体力劳动。。。。。
我干的原来有老系统的多
所以表驱动开发好久没用过了

多谢抛出异常的爱, 太长了, 不引用了.
我赞同你的说法,  我觉得从顶向下的设计方式的话, 实际上dto肯定不是po, 需要通过控制类进行转换, 而如果以数据为中心的话, 可以直接传输po, 需要客户端根据po来进行数据的选择.

不过我现在碰到一个问题, 这个问题可能会导致让我无论如何都转换po, 区分出dto和po.
我在容器内使用hibernate的级联功能, 映射成set, 但hibernate内部会构造出一个内部的set类的派生类(代理类)来实现这个set. 业务方法正确return,容器也正确返回给客户端.  但当客户端捕捉到异常 java.io.InvalidClassException: org.hibernate.collection.AbstractPersistentCollection. 方法调用失败. 我分析下来感觉是客户端无法反序列华这个hibernate内部的Set类的子类. 所以反序列化失败.
同样的代码如果不通过ejb调用,直接在本地调用的话, 没有任何问题, 原因是不需要反序列化.
不知道是否是我没有正确理解hibernate. 如果按我现在的分析来看, 感觉在ejb中使用hibernate, 除非不使用cascade, 不然都需要区分出dto和po的.

另外,如果不转换po和dto, 又要使用cascade的话,  可能也可以修改set****(Set ) 和get***(Set )方法, Po中不设置Set的私有变量, 通过修改上面两个方法, 直接转换成对应的具体的类的数组. 不让Po中包含Set, 而是包含转换后的具体的子对象的数组, 这样也行.
不知道hibernate本身是否有什么方法解决这个问题?, 没有看到别人在直接使用Po作为dto时出现过这种问题啊.

深有感觉，项目刚开始做的时候，用最原始的方法，若要增加一个字段，就需要从jsp改到dao，痛苦的要死，但是慢慢在开发的过程中学会使用formbean，若增加一个字段，只是需要在mode中添加其属性和页面加上该字段就可以了，其他都必要改动；