请教Struts架构设计问题：DAO + VO + (Struts)Action + (Struts)ActionForm

第一个问题：
formbean 和 VO(如果我没有理解错，指的是ValueObject吧)的功能是不一样的。
一个是帮助你把request中的Name-Value's MAP->Object.至于VO,我觉得既可以是一个很大的概念，通指不同层之间传输数据的容器。那么sharedata (琴心剑胆逍遥客)说的VO,指的是不是仅仅是传给DAO使用的数据容器？既然两个东西在概念上是不同的（尽管内容差异较小）一般来说应该没有复用的可能，否则恐怕不太好。
另外不知道sharedata (琴心剑胆逍遥客) 所说的DAO是不是那种简单的DAO,就像petStore中的DAO一样。第二个问题：
我和sharedata (琴心剑胆逍遥客) 有不同看法。
DAO的出现是为了抽象出数据库操作使得你可以专注于业务逻辑的实现而不用分心于对数据库的操作，同时可以在某种程度上实现复用。至于EJB，它和DAO不是相互替代的关系（如果说EntityBean的话，可能还有一点相似）。
当然，现实中能否做到是另一回事。如果整个系统业务逻辑简单也不考虑扩展的话，不用DAO，把对数据库的操作封装到一个或几个方法里面也是可行的。
VO的采用确实可以提高网络传输效率（减少传输次数），能不能使结构清晰我不知道。第三个问题：
如果第一第二个问题解决了，这个问题也就自然解决了。大家多讨论

supersonics(落叶狂风) 说的是不错的，实际上，我这里的设计考虑到项目组的人员的水平，已经裁减掉了很多的层，如对DAO上面的一层或者多层。我还是主张分离的实现或者不使用FormBean的方式（该方式相对理解困难些），但结构和扩展我喜欢。 jiganghao(JH) 谢谢你的关注，但客观的说对我没有实际的意义。
xbt(xbt) 谈谈你的解决方式吧。总的来说，涉及是在各种方案中根据项目的开发人员水准、项目实际情况的一种综合取舍，因此，希望大家多谈谈自己的感受。

1.
如果你要減少 actionForm 與 vo 重複的 code
因為可能都是一些 getter 與 setter 的動作 ex. getAbc() , setAbc(),
你可以嘗試使用 DynaActionForm, 僅僅需要在 struts-config.xml 設定
接著, 在程式中使用 jakarta commons-beanutil 的 PropertyUtil
透過 copyProperties 將 DynaActionForm 的資料放到 VO
(ps. 其實我是放到 TO , 我本身有 TO/BO/VO, 不過小系統使用 VO 即可 )2.
VO 與 DAO 的關係最重要的就是實作出 O/R Mapping
而透過 VO 的整理實現出有效的資料
例如資料庫放入的日期格式是 char(8) 20031101
我需要轉換成 2003/11/01, 才能在我的 Business Logic 運算中使用
更包含了送到 view 端顯示等等的修改與運算
當然, 未來如果你的 DAO 改成 EntityEJB / JDO 甚至是透過 hibernate 封裝
都會比較容易,
此外, DAO 不僅僅是存取資料庫, 還包含了存取檔案, Legacy Data, LDAP 等

supersonics(落叶狂风)说的很好 formbean把request中的Name-Value's MAP->Object.同时有数据校验的功能,
它的出现是struets中为了解决页面数据校验、页面数据的显示
DAO的出现是为了抽象出数据库操作使得你可以专注于业务逻辑的实现
VO（ValueObject）,不同层之间传输数据的容器。
弄清几者的区别我想楼主就不会发愁了页面的form表单--formbean--实体类对象--valueObject--DAO(或者EJB)--数据库中的表
就数据层面说大家可以看到一个有意思的数据流楼主说的:"VO 和FormBean 都是对数据的封装，所以功能有重复的地方"
我不同意，以上提到的几个概念是都是对数据的操作，但功能怎么说就重复了呢
看一个类要看它的责任
不能说有相同的数据有重复的setter、getter方法就认为是一样的了
进而让VO 扩展 (Struts)ActionForm 更是错误
“程序员使用的时候很可能混合使用这两个类”也是你这样‘扩展’造成的每个概念的出现都有它的原因的，
表现层的使用formbean,实体类
业务层的使用实体类、值对象
数据层的使用值对象、EJB、DAO、JDO等大家多讨论

用 DynaActionForm我觉得有些局限，就象我写structs的时候，有些就不用TAG，如果你用 DynaActionForm就必须用TAG，FORMBEAN和VO该是两马事吧

to oldfisher(渔夫) 減少工程師開發的時間
最重要的就是減少 code 的開發
如果對應的資料是相同的
VO 和 ActionFormBean 的重複性非常高
因此, 為何不讓他存在一個就可以了
而且, 透過 beanutils 可以減少開發 get set 的動作
希望你們能夠仔細研究.. ^^"to along603(给分不心疼，给不出去才心痛) 你可能對 DynaActionForm 太不了解了
應該是 request 送到 ActionServlet,
如果有 ActionMapping 的 action 存在
則會去根據他設定的 ActionForm,
不論是否為實體的 ActionForm.class 或 DynaActionForm

to jakarta99(99% jakarta):就你的原文发表一下个人意见，不妥之处还请海涵。
---------------------------------------
如果對應的資料是相同的
VO 和 ActionFormBean 的重複性非常高
因此, 為何不讓他存在一個就可以了
---------------------------------------
记得以前我问过阎博士一个问题，为何正方形不能作为矩形的子类（记得小学时我们就学过正方形是矩形的特例的知识）？
这个问题的答案也可以用来回答你的问题。会不会以不同的眼光来看待这两种class.我认为会的。所以我觉得至少从理论上说：分成两个class是有必要的，可以使结构更加清晰，可维护性也更好。
为什么我认为会？很显然，作用就不一样：一个作为client过来的数据的容器，一个作为请求DAO操作的parameter的容器（暂时只考虑一个方向的数据流动）。
回到实际来说，如果DAO是那种比较简单的DAO（每个方法都只做一次简单的数据库操作）,很显然把FORMBEAN传给DAO是不合适的。另外，如果合并，难免存在只对client有效和只对DAO有效的项目，这很容易造成混乱（特别是在维护的时候）。

to supersonics(落叶狂风), 您太客氣了, 大家都是相互學習中可能我寫的不夠明確.... :P應該是說, 我是利用 DynaActionForm 來取代真正的 ActionFormBean 的開發
但是真正和 DAO 溝通的, 當然是使用 VO 來作處理
所以我才會提到透過 common-beanutils 來做資料的轉移
dynaFormBean <-> VO .一則減少 abcVO.setXyz( FormBean.getXyz()) 這種程式碼的開發
二則讓維護更為容易此外, 為何 struts 1.1 會製作出 DynaActionForm extends DynaBean
最重要的原因, 我舉個簡單的例子來說
updateUserProfile.do
如果你對於 UserProfile 這個 table　製作一個 UserProfileVO
和 UserProfileFormBean　的重複度
可以發現相似度非常的高,　而且幾乎 getters / setters　幾乎都是一樣
所以我會建議將 UserProfileFormBean　轉換成為由 controller　根據
struts-config.xml　所產生的虛擬 DynaFormBean.. ^^"至於, struts　有蠻多 ide　會幫你製作這些相關的物件,
但是維護上卻發現非常的凌亂...　
因為太多相似的 class　將會導致太多時間去修改相同的地方

to jakarta99(99% jakarta):不好意思，看来是我误解您了。
您的意思不是把VO和FORMBEAN合并，而是不使用FORMBEAN这样显著的class，采用DynaFormBean来控制代码量。
这样当然没有问题。我和您原来争论的焦点在于是否用一个class来完成两个容器的功能，现在当然在这点上我们是一致的。只不过我说的FORMBEAN是一个实实在在的class,而您采用的是DynaFormBean的方式来实现FORMBEAN的机能。
至于您所说的common-beanutils，是不是指的apache-jakarta提供的一个工具？我不是很熟悉，可能要花时间去看看。
您举的updateUserProfile.do例子我有个疑问，在实际开发中，象这样简单的业务是不存在的（我连一次都没有遇到过），也就是说，一般情况下，一个FORMBEAN的内容会包含若干个VO的内容。如果这样的话，不知道使用DYNAFORMBEAN还是否合适。顺便说一下，我只是用过struts1.0,1.1还没有机会使用。
多多指教。

to jakarta99(99% jakarta) :
---------------------------------------
減少工程師開發的時間
最重要的就是減少 code 的開發
如果對應的資料是相同的
VO 和 ActionFormBean 的重複性非常高
因此, 為何不讓他存在一個就可以了
而且, 透過 beanutils 可以減少開發 get set 的動作
---------------------------------------为减少相同的getter,setter代码把两个不同职责的类合在一起这一点我太难苟同一則減少 abcVO.setXyz( FormBean.getXyz()) 這種程式碼的開發
二則讓維護更為容易维护更为容易吗？虽然两个类的代码合在一起代码数量是少了
但维护人员一点都不轻松如此结构不清晰的代码如何看的懂？
“程序员使用的时候很可能混合使用这两个类”
开发人员都会弄混何况维护人员
为少写几个getter,setter 就把软件设计的单职责原则忘了？不同的类有不同的职责不同的概念自有它自己的用处强扭的瓜一点都不甜是吧

to oldfisher(渔夫)
希望你先去研究一下所謂 jakarta commons-beanutils
我們再來討論為何可以讓維護更為容易 :P
而且我相信我上一篇已經對於爭論的地方說明的更為仔細了
希望你能夠明白...to supersonics(落叶狂风)
感謝你願意和我討論 :)
當你製作資料庫資料管理介面的時候,
就會用到 1:1 的 table 的情況了.

我們還是拿 updateUserProfile.do 來說好了.
如果需要修改到的是 UserBasicEntityBean & UserOtherEntityBean
基本上, 我會將他放到所謂的 Customized ValueObject , 就不是 1:1 vo <-> entity 的情況
也有人稱為這種為 BusinessObject.
我會將 formbean data 放到 bo , 接著, bo 與各個 vo/dao/entity 的動作
即使我不說, 你大概也會知道該如何實作..
這有什麼好處呢, 當你有任何 rollback 或是 resultData 都應該記錄在 BO , 最後再丟回 formbean 中..
我在維護的時候, 由 BO 就可以知道目前處理的資料流是如何了..

there are multiple bean/VO in current j2ee framework. here is my idea about using them:form bean/dyna bean: belongs to struts framework, used between client tier (html form) and presentation tier.transfer object (TO): used for transferring coarse-grained data between tiers (presentation and busines, business and integration), and/or remote calls between physically distributed systems.DAO: encapsulate both DB data and access logic. it can be used separately, or jointly with entity bean.business object: a new core j2ee pattern. it represents a conceptual domain model with business logic and relationship. it is independent of wire protocol (eg. client types) and persistence framework (eg. db platform or legacy system). it is abstract, which can be implemented by POJO/entity bean/DAO.session bean: a j2ee API providing business service. so it is closer to client than business object and entity bean, but not than business delegate/service locator.entity bean: another j2ee API, providing persistent transactional business components. it is an component, not as conceptual as business object; yet it is ASSUMED to be platform free with support from complicated SQL_EL language. it has n+1 problem, entity-relation problem. so programmer talk more about DAOas an alternative.java bean: the basic buiding block specification (also an self contained java class) for all java objects, including all montioned above. struts/jsp tags, ejb, reflection, etc. all depend on this standard structure. so try your best make every java object a java bean.

to jakarta99(99% jakarta) :
恕我愚钝，还是不太明白，需要您的指点.
----------------------------------------
這有什麼好處呢, 當你有任何 rollback 或是 resultData 都應該記錄在 BO , 最後再丟回 formbean 中..
我在維護的時候, 由 BO 就可以知道目前處理的資料流是如何了..
----------------------------------------
这个好处还不足够让我觉得有使用BO的必要。我到SUN的网站上查了一下，BusinessObject是新加入的一个Pattern，说明如下：
An object that implements business logic and/or business data. Business data and business logic are implemented in coarse-grained objects called Business Objects. In J2EE, business objects are implemented as session or entity beans. In some cases, a business object could be an arbitrary Java object that provides some service.
感觉是说把BUSINESSLOGIC封装到一个组件当中去。这个组件是一个SessionBean或EntityBean组成,或者是一个普通的class组成，这个class提供一些Service(还是组件的概念）。
如果业务复杂，那么就有必要把业务封装到一个class中去，在考虑到transaction等问题，封装到一个EJB中。
但是我觉得这样做的好处正如 jiganghao(JH) 说（？）的：it is independent of wire protocol (eg. client types) and persistence framework (eg. db platform or legacy system).比如业务逻辑可以让struts的Action来调用，也可以通过webservice来调用，实现了业务逻辑对client解耦（考虑到当前对应多种client端的需求呈上升趋势）。
至于resultData等情报是否存在BO内，我持怀疑态度。我个人崇尚stateless的方式，即通过方法返回值返回。

难道你写DynaActionFrom ，在JSP中不是用标签？用标签的时候你有没有碰到过标签不能用，需要加入<%%>代码的时候？public class DynaActionForm extends ActionForm{}
他是直接根据JSP上面的标签对应的吧，其实ActionForm的代码量完全没有考虑的必要，他不存在出错的问题，只是将多个VO里面的东西拷贝到其中，哪怕是没用的东西在里面也不会产生影响

从各位的回答来看，绝大部分人的经验和技术都很好，我这里再说说我的看法。1：VO和FormBean在功能来看是有区别的，但是，代码是有重复的。我考虑的重点是如何避免程序员少写重复代码。我最后的选择是两者都要。顺带的说说其它的选择，对于“(Struts)ActionForm 中对 VO 进行代理的访问”和“VO扩展 (Struts)ActionForm 并实现序列化”上面已经描述了他们带来的负面问题。这里说说动态表单和用一个(Struts)ActionForm 来替代。
（1）：动态表单增加了配置的复杂程度，并紧密耦合Struts，并且会破坏系统风格的一致性。至于你可以通过一些手段来映射成为VO，但这种处理增加了系统实现的复杂程度，也是不好的设计。
（2）：一个(Struts)ActionForm 确实可以用来替代VO，但是，会带来这些问题：两者本身是不同的，混淆用法不好；(Struts)ActionForm 在继承结构上会带来很多的无用的东西，代替VO时会增加系统的开销；和Struts耦合紧密，不是好做法；在一些细节的地方这种实现可能带来意想不到的问题（注意，是可能不是绝对）。2：设计考虑。什么是好的设计，你需要关注的问题包括：耦合降低、结构清晰、实现简单、扩展容易（这些是很多的设计人员不注重的，当然，还有其它的设计要素），在这里，各位的设计，包括我想到的各种情况，都是可行的，问题的关键其实是“如何从程序员的角度出发考虑问题”。所以我问大家如何减少重复并降低耦合、提高设计清晰度。3：jiganghao(JH)，谢谢你的关注，如果想要更好的讨论，请使用中文。

to supersonics(落叶狂风) 我之前提的解釋可能不是很好,
使用 BO 這個名稱會和 corej2eedesignpattern(II) 中的 BO 產生混淆我們回歸到問題的核心
該如何應用 ActionForm 與 VO 的對應關係假設 jsp 有 idno, password, name, telephone 輸入框需要修改
影響的 Table 有 User ( id ,password, name) <--> UserTelphones ( id, telephone ) 這樣的關係在開發的過程中, 我們會很簡單的分配成為兩個 teams
(1) Web-tier develope team
(2) Business-tier develop team首先, 我們必須定義出所謂的 BusinessDelegate Interface
提供給雙方有開發的依詢,
此外, 我們會提供一個 VO ( UserDataVO ) 給予雙方使用
VO 會包含
long id;
String password;
String name;
Collection telephones; // for 1:n relationship
1. Web-tier view
為何我說可以減少維護的地方, 就是我已經擁有了共同開發的 VO,
何必要繼續建立一個 ActionForm.class,
因此我建議採用 DynaActionForm, 在 struts-config.xml 中設定就可以了
當我的 Action 接收到 DynaActionForm
就把所有的資料放到 VO ( 透過 jakarta commons-beanutils )
接著呼叫 BusinessDelegate 中的 updateUserData(VO) 將資料傳到 business-tier
當然, 如果你要用 DynaValidatorActionForm 做基本檢核也可以
或是, 你要在 Action 中做一些基礎的資料檢核2. Business-tier view
當 Delegate 呼叫 Business Logic 的 SessionBean,
也許是 stateful / stateless ( stateful 往往是用在 transaction )此時, 如果傳入的 VO 需要更多資料來輔助這個 VO 時
我會增加一些 attributes 給予 VO,
例如我要有一個 md5password attribute 這種情況等等.
此時的 VO 的屬性, 與 web-tier 的屬性不同
我會放入一個 BO 之中, 當然, 這麼簡單的情況下...
你也可以一開始就定義有 md5password 這個欄位當 business processor 擁有 BO 的時候,
自然可以成為一個 Manager 對於 DAO 做動作
也許去取得其他的 VO 來作為比對資料/ 驗證資料/ 計算資料
最後, 我可以呼叫 UserDAO 分別作
setUser() 及 setUserTelphone() 等等的動作
因為 cmp ejb 不建議傳入 vo ,
所以就會在 business tier 將資料分別放入...唉... 真是不好敘述.. 請多包涵 -.-"

I agree with points of jakarta99(99% jakarta). he gave the typical calling sequences from web client, to struts form bean and action class, then populate input VO, call business methods, get output VO, then jsp views show result using struts tags.to sharedata(琴心剑胆逍遥客): i am sorry that i cant input chinese; also I dont know some translated chinese jargons.

怎么说呢，用DynaValidatorActionForm其实就相当于使用了ActionForm

to jakarta99(99% jakarta):
--------------------------------------------------
在開發的過程中, 我們會很簡單的分配成為兩個 teams
--------------------------------------------------
一般只有当需求被充分理解并且不会频繁变更时才能以这种方式作业。
你的意思我了解了。感谢您费心费力的指导说明。to sharedata(琴心剑胆逍遥客):
问题解决了就好，我也从中学了不少东西。

我也是这么干的，呵呵，不过我认为这是最糟糕的设计了，！
大，高性能，就用ejb吧
中等性能要求不是很高，就用一些持久工具，比如说是jdo,hibernate
小的网站网页，写写jsp+servlet,就可以了，加javaben,和tag ，自定义tag.

我刚刚做了struts不久，做一个网站程序，规模不大。
因此我采用actionfrom+action+bo+vo+dao。以前我一直采用两层结构，现在一个很简单的工作要分到多个程序中去实现，很麻烦。
因此我做了一个程序根据数据表根据程序模板自动生成vo,dao程序，然后根据vo可以生成自动生成多个formbean（暂时没有采用DynaActionForm, 也不难，就是直接生成struts-config中的配置文件）。
这样一来，手工直接的代码编写量减少了很多,也不容易出错误。

crazymens(风)：
你说你做了一个程序根据数据表根据程序模板自动生成vo,dao程序，请问你做到了什么程度了？描述一下好吗？ sjie_ji(青藤)：
你说的是大概的思路，我基本同意你的观点，但大概思路那是不够的，至少使用EJB在设计、开发、成本（开发和售价）、程序员水平等各方面的要求就是不一样的，特别的，EJB会涉及到很多的设计模式来提高性能，这点很多的人不明白的。还有，你提到这种设计很糟糕，我想知道糟糕在哪里？设计的层次确实是个问题。“层”，通常带来结构的清晰，也带来结构的庞杂，什么养的设计是合理的常常根据实际的情况来取舍，一个是项目时间，一个是扩展和升级，一个是人力资源。其他（重要的）呢？我们的讨论可以更开阔些思路来讨论。

to crazymens(风) and others:
to use struts and other j2ee techniques (e.g. ejb), much declarative configuration is required (it is called externalization), but it is good: code is simple, configuration delayed to deployment phase, configuration values tuned for differenct running environment without changing code.such property or configuration file is a do-it-once-and-reuse-later style. you do need design or understand framework doc to make first-time responsibility allocation/configuratoin work; but once it is done, maintainence is a lot easier. any new change mostly happens in one place, with other parts untouched, especially code.to reduce amount of coding or avoid code-cut-and-past, you can write infrastruture utilities or use other java/design pattern techniques. one of my friends used doclets to automatically create all VO classes but i donno the details. java reflection is another alternative. dyna bean is still another. template can reuse most common workflow logic. 'struts in action' gave an example of abstract action class (with a method doExecute() to be inherited), which is very useful.I dont think exact how many lines of code matters as much as in older languages as assembly or C. design/coding idoms like 'write once and only once' and 'you dont need it' are most important to produce simple, reusable code.

你可以用HASHMAP来处理VO和FORMBEAN的问题。但这样做需要完全颠覆你以前的OO理念。其实也不是颠覆，只是对OO来讲，怎么看的问题。你可以将HASHMAP理解为一个数据对象。当然这个数据对象是抽象的。如果你能这样理解。那么从数据库到JSP或从JSP到数据库。就很简单了。完全不用维护什么VO，FORMBEAN之类的玩意儿。（我所理解的VO是指ValueObject？）关于目前基于数据库系统的开发。个人理解并不适合通常意义上的OO概念。最适合的开发模式应是基于数据库模型的开发，而不是基于对象模型的开发。在做数据库系统的开发时。传统上我们很多工夫都花在对数据库模型在系统里用OO来进行重建。其实这是没有多少意义的而且也是很浪费时间和精力的一件事。

vo和actionform在很多时候是不一样的，actionform主要是为界面服务，它包含了界面上要显示的数据，如vo很多时候都是和业务偶合，却独立于界面的显示部分。举例来说，假设界面中一个select框，里面包含了很多option，对于这样的界面，vo的属性往往只有与select的name相对应的一个属性，而actionform可能还多包含了一个属性，就是存放option数据的集合属性。当然actionform还可能包含了各种与操作相关的属性，比如它的一个属性可能和一个按钮相对应，而这些都是在vo里不存在的，记住一样东西很重要，那就是actionform属于view相关的部分。至于vo从fomr里继承是绝对错误的选择，因为这样的结果将使系统将表现层的逻辑带入了业务层。但作为选择让form继承vo倒是一个可考虑的方法，但不推荐。至于vo到form之间的属数据传递问题可以写一个工具类，来自动递归拷贝相关属性。
dao的一个重要特性就是它分离了数据持久层。

我刚工作不久，现在做一个很大的的项目，采用struts技术
我们的结构是Action＋DynaValidatorActionForm + Command + DAO + VODynaValidatorActionForm可以对页面上得到的数据进行一般的类型校验，只要在validation.xml中配置即可Action 主要用来封装页面上的来得数据给Command使用，同时还从Command接受数据并传递给页面，还对数据进行必要的逻辑判断，我们还使用dispatch技术Command主要是进行逻辑判断并调用DAO对数据库进行操作，VO中的数据就是在这里set进去的
Action 和Command 的关联是用xml配置的DAO,VO使用工具依据数据库自动产生，VO只是用来封装数据的容器，以方便DAO使用。ＤＡＯ对数据进行查询，插入等工作，以VO为参数我们的风格很严谨，比如在Action中是绝对不容许调用Command或DAO的；我们还提供一个本模块的Wrapper类，专门用来存放公共方法和调用外部模块的数据或方法（不能以其他方式直接调用，更不能在Action中直接调用）；另外我们还有一个本模块的Bizlogic类，专门用来存放用来进行逻辑判断的方法

youfly(无名) 举的例子很有说明性
我们也是这样做的
"vo从fomr里继承是绝对错误的选择，让form继承vo是一个可考虑的方法" ：）"至于vo到form之间的属数据传递问题可以写一个工具类，来自动递归拷贝相关属性。"
jakarta commons-beanutils 就是这样的工具
反过来不能因有了这样的工具类而让vo和formbean混淆不清就不好了

呵呵，谢谢你的认可。不过jakarta commons-beanutils完成这样递归拷贝似乎不太可胜任，编写自已的工作还是有需要的。

it is a pity that form bean uses servlet api. this makes the form a mixture of view data and model data, and leads to misunderstanding. so in most cases, an abstract DTO is still necesary. form bean cant be a DTO.

就象你说的，我觉的你用session bean也是不错的选择，不会有什么速度问题。
过于复杂的层次设计，会让你的开发人员觉的迷忙

我个人认为actionForm和vo虽然貌似但神离。在表现层中用actionForm
，其它层中数据传递用vo,目前我参与的项目就是这样：在action中
通过actionForm得到相应的表现层数据，然后将数据封装到vo中，那么以后层
之间的数据传递就都靠vo了。

层与层的结构，还是分成两个class为好，不管是从维护还是重构的角度来看，两者
都有存在的必要。

上面的探讨很好，可以看出，大部分人的技术都是很好，呵呵，幸会啊！我的QQ是9818376，我是一个设计人员，96年开始学Java的（不过水平一般），愿意的可以交交朋友。下面也有一些问题，也希望朋友们能够多多的指点。难题]请教数据懒加载的具体实现技术
http://expert.csdn.net/Expert/topic/2503/2503266.xml?temp=.7366297[强调通用]Java数据访问层如何实现通用分页？！各种实现的优劣。
http://expert.csdn.net/Expert/topic/2499/2499196.xml?temp=.9645807

我的理解是
DynaForm -> action -> Facade(BO)，Facade组装VO->DAO->VO必须要有一个中间层来区分和处理form与VO的转换反之将VO传到jsp的话，要
Vo->DAO->facade生成DTO->action->jsp

wrap封装
vo封装formbeanformbean属于view layer
vo和dao属于数据持久层
不可多层偶合
要考虑formbean修改(经常发生),数据层不改变
数据层改变,formbean不变的情况

可以拓展话题到 DAO 模式下对事务的处理，也可以更拓展的探讨事务处理。谢谢上述所有的朋友们！

推荐使用Torque最为数据持久层

调试易

请教Struts架构设计问题：DAO + VO + (Struts)Action + (Struts)ActionForm

解决方案 »