在 struts+ hibernate 这种结构中，是不应该把Hibernate产生的PO直接传递给JSP的，不管他是Iterator，还是List，这是一个设计错误。www.huuoo.com7 x! x$ a: u: `( E; a
& \, C- B U4 A. ?$ E+ K8 Y我来谈谈在J2EE架构中各层的数据表示方法：www.huuoo.com/ B r9 d' {$ G3 q- A
Web层的数据表示是FormBean，数据来源于HTML Form POST
/ u' M5 y+ |5 l, K( k忽悠,忽悠社区,忽悠论坛.业务层的数据表示是VO www.huuoo.com. l- e* W. \1 e* R% {: h
持久层的数据表示是PO，其数据来源于数据库，持久层的数据表示例如CMP
' X* i1 }! ]' a0 {忽悠,忽悠社区,忽悠论坛.忽悠社区* H, R$ g" }, e
在一个规范的J2EE架构中，不同层的数据表示应该被限制在层内，而不应该扩散到其它层，这样可以降低层间的耦合性，提高J2EE架构整体的可维护性和可扩展性。比如说Web层的逻辑进行了修改，那么只需要修改FormBean的结构，而不需要触动业务层和持久层的代码修改。同样滴，当数据库表进行了小的调整，那么也只需要修改持久层数据表示，而不需要触动业务层代码和Web层代码。忽悠,忽悠社区,忽悠论坛.2 q4 ? G4 l0 N
www.huuoo.com8 ^: P) ]) ?* X$ j9 ]
不过由于Hibernate的强大功能，例如动态生成PO，PO的状态管理可以脱离Session，使得在应用了Hibernate的J2EE框架中，PO完全可以充当VO，因此我们下面把PO和VO合并，统称为PO。忽悠,忽悠社区,忽悠论坛.4 b, \3 G# G0 [% K) c: g' J
4 E+ v8 N. {5 F6 M( w0 u) F( J3 A先来谈谈ActionFormBean和持久层的PO之间的重大区别。忽悠社区是综合性社区网站,将最新、最快、最专业的资讯、新闻,图片,视频奉献给所有爱好者。- s( q; I: {( z: k% d4 C
! F' |# V( `3 E9 i- }3 h6 n在简单的应用中，ActionFormBean和PO几乎是没有区别，所以很多人干脆就是用ActionFormBean来充当PO，于是ActionFormBean从JSP页面到Servlet控制层再到业务层，然后穿过持久层，最后一直映射到数据库表。真是一竿子捅到了底！
8 B& n3 x1 V4 [4 @# h忽悠社区是综合性社区网站,将最新、最快、最专业的资讯、新闻,图片,视频奉献给所有爱好者。
6 g, z9 O% p( j7 X' ^www.huuoo.com但是在复杂的应用中，ActionFormBean和PO是分离的，他们也不可能一样。ActionFormBean是和网页里面的Form表单一一对应的，Form里面有什么元素，Bean里面就有什么属性。而PO和数据库表对应，因此如果数据库表不修改，那么PO也不会修改，如果页面的流程和数据库表字段对应关系不一致，那么你又如何能够使用ActionFormBean来取代PO呢？
' a4 ?) @. z" Z- {8 y8 y/ V: j" ~+ J2 i* s3 a" Y2 D
比如说吧，用户注册页面要求注册用户的基本信息，因此HTML Form里面包含了基本信息属性，于是你需要一个ActionFormBean来一一对应(注意：是一一对应)，每个Bean属性对应一个文本框或者选择框什么的。忽悠社区2 i* }* b5 @4 g; v
+ s$ N- r+ E; V! \' u忽悠,忽悠社区,忽悠论坛.而用户这个持久对象呢？他的属性和ActionFormBean有什么明显不同呢？他会有一些ActionFormBean所没有的集合属性，比如说用户的权限属性，用户的组属性，用户的帖子等等。另外还有可能的是在ActionFormBean里面有3个属性，分别是用户的First Name, Middle Name, Last Name，而在我的User这个持久对象中就是一个 Name 对象属性。
( D! }5 x: C, E忽悠社区忽悠,忽悠社区,忽悠论坛.: M" o% x7 n7 J3 D
假设我的注册页面原来只要你提供First Name，那么ActionFormBean就这一个属性，后来我要你提供全名，你要改ActionFormBean，加两个属性。但是这个时候PO是不应该修改滴，因为数据库没有改。忽悠社区& f: H3 A' u$ A) N/ N8 [( y
0 @' G* i8 W5 a! d那么在一个完整的J2EE系统中应该如何进行合理的设计呢？
) V: _/ w8 k- q% U9 W) q/ p忽悠社区! X4 G2 h N! }- O* P- Q
JSP(View) ---> ActionFormBean(Module) ---> Action(Control)" }* m' V/ }5 T: u T( i! c
3 U4 w6 S s- g5 yActionFormBean是Web层的数据表示，它和HTML页面Form对应，只要Web页面的操作流程发生改变，它就要相应的进行修改，它不应该也不能被传递到业务层和持久层，否则一旦页面修改，会一直牵连到业务层和持久层的大面积的代码进行修改，对于软件的可维护性和可扩展性而言，是一个灾难，Actiont就是他的边界，到此为止！
4 h) \) K* c: B* M- F* M. \
" g5 @. [# V2 rwww.huuoo.comAction(Web Control) ---> Business Bean ---> DAO ---> ORM --->DB" X2 t2 Q( A" B3 q
# ~- N/ J# I0 F忽悠,忽悠社区,忽悠论坛.而PO则是业务层和持久层的数据表示，它在业务层和持久层之间进行流动，他不应该也不能被传递到Web层的View中去，而ActionServlet就是他的边界，到此为止！忽悠社区# F3 _" b6 p9 C2 r- C
忽悠社区是综合性社区网站,将最新、最快、最专业的资讯、新闻,图片,视频奉献给所有爱好者。' U$ R/ {2 H8 b& }# x/ o. T# _
然后来看一看整个架构的流程：忽悠社区是综合性社区网站,将最新、最快、最专业的资讯、新闻,图片,视频奉献给所有爱好者。5 |4 O3 w. [! B3 o
www.huuoo.com; @. r' G. u! x* ]8 r
当用户通过浏览器访问网页，提交了一个页面。于是Action拿到了这个FormBean，他会把FormBean属性读出来，然后构造一个PO对象，再调用业务层的Bean类，完成了注册操作，重定向到成功页面。而业务层Bean收到这个PO对象之后，调用DAO接口方法，进行持久对象的持久化操作。忽悠社区, Z3 e4 [ e2 j8 v
$ g& A) L9 w. A忽悠社区当用户查询某个会员的信息的时候，他用全名进行查询，于是Action得到一个UserNameFormBean包括了3个属性，分别是first name, middle name, last name，然后Action把UserNameFormBean的3个属性读出来，构造Name对象，再调用业务Bean，把Name对象传递给业务Bean，进行查询。8 c' K+ h* ?1 D2 N" J0 c5 V
( |( h* w% P: U忽悠社区业务Bean取得Name(注意: Name对象只是User的一个属性)对象之后调用DAO接口，返回一个User的PO对象，注意这个User不同于在Web层使用的UserFormBean，他有很多集合属性滴。然后业务Bean把User对象返回给Action。! O) Z. K+ O7 J2 j
Action拿到User之后，把User的基本属性取出(集合属性如果不需要就免了)，构造UserFormBean，然后把UserFormBean request.setAttribute(...)，然后重定向到查询结果页面。
5 `7 s2 v' C/ S: d* U/ ?" M忽悠,忽悠社区,忽悠论坛.
4 C: r& ], i' `9 p7 i+ S忽悠社区查询页面拿到request对象里面的ActionFormBean，自动调用tag显示之。, r7 o8 y2 Q- o
忽悠社区是综合性社区网站,将最新、最快、最专业的资讯、新闻,图片,视频奉献给所有爱好者。9 Y" F4 e L0 |3 f L
总结：
( ]4 U3 d7 B) Z8 P8 y# DFormBean是Web层的数据表示，他不能被传递到业务层；PO是持久层的数据表示，在特定情况下，例如Hibernate中，他可以取代VO出现在业务层，但是不管PO还是VO都必须限制在业务层内使用，最多到达Web层的Control，绝不能被扩散到View去。
R6 n6 x! ^! o* Fwww.huuoo.comFormBean和PO之间的数据转化是在Action中进行滴。
+ U2 ?- q j/ H- e0 `% e6 ~$ B5 W, E' L( Y
BTW:
$ |1 ]; _) \: w5 J% k忽悠,忽悠社区,忽悠论坛.JDO1.x还不能像Hibernate功能这样强大，PO不能脱离持久层，所以必须在业务层使用VO，因此必须在业务层进行大量的VO和PO的转化操作，相对于Hibernate来说，编程比较烦琐。
@% N |3 r0 N Y/ Q1 Q当然咯，理论是一回事，实际操作也不一定非要这样干，你可以自行取舍，在实际项目中灵活一点，增加一点bad smell，提高开发效率。只不过在大型项目中最好还是严丝合缝，不然的话，改版的时候会痛苦的很滴。 |
