因為Spring自帶的sample離我們的實(shí)際項目很遠，所以官方一點(diǎn)的model層模式展現就靠Appfuse了。
但Appfuse的model層總共有一個(gè)DAO接口、一個(gè)DAOImpl類(lèi)、一個(gè)Service接口、一個(gè)ServiceImpl類(lèi)、一個(gè)DataObject.....大概只有受慣了虐待的人才會(huì )欣然接受吧。
另外，Domain-Driven逢初一、十五也會(huì )被拿出來(lái)討論一遍。
其實(shí)無(wú)論什么模式，都不過(guò)是一種人為的劃分、抽象和封裝。只要在團隊里理解一致，自我感覺(jué)優(yōu)雅就行了。
我的建議是，一開(kāi)始DO和Manager一生一旦包演全場(chǎng)，DO作為純數據載體，而Manager類(lèi)放置商業(yè)方法，用getHibernateTemplate()直接訪(fǎng)問(wèn)數據庫，不強制基于接口編程。當某天系統復雜到你直覺(jué)上需要將DAO層和Service層分開(kāi)時(shí)，再分開(kāi)就好了。
1.DataObject類(lèi)
好聽(tīng)點(diǎn)也可以叫Domain Object。Domain Driven Development雖然誘人，但因為Java下的ORM框架都是基于Data Mapper模式的，沒(méi)有Ruby On Rails中那種Active Recorder的模式。所以，還是壓下了這個(gè)欲望，Data Object純粹作一個(gè)數據載體，而把數據庫訪(fǎng)問(wèn)與商業(yè)邏輯操作統一放到Manager類(lèi)中。
2.Manager類(lèi) 我的Manager類(lèi)是Appfuse中DAO類(lèi)與Service類(lèi)的結合體，因為：
2.1 不想使用純DAO 以往的DAO是為了透明不同數據庫間的差異，而現在Hibernate已經(jīng)做的很好。所以目前純DAO的更大作用是為了將來(lái)可以切換到別的ORM方案比如iBatis，但一個(gè)Pragmaic的程序員顯然不會(huì )無(wú)聊到為了這個(gè)機會(huì )不大的理由，現在就去做一個(gè)純DAO層，項目又不是Appfuse那樣為了demo各種ORM方案而存在。
2.2 也不使用純的薄Service層
在JPetStore里有一個(gè)很薄的Service層，Fascade了一堆DAO類(lèi)，把這些DAO類(lèi)的所有方法都僵硬的重復了一遍。而我認為Fascade的意義在二：
一是Controller調用Manager甲的時(shí)候，總會(huì )伴隨著(zhù)調用Manager乙的某些方法。使用Fascade可以避免Controller零散的調用一堆Manager類(lèi)。
二是一個(gè)商業(yè)過(guò)程里可能需要同時(shí)調用DAO甲乙丙丁的方法。
這些時(shí)候，Fascade都是合理的。但我討厭類(lèi)膨脹，所以我寧愿在甲乙丙丁中挑一個(gè)來(lái)充當Fascade的角色。有耦合的問(wèn)題嗎？對一個(gè)不是死搬書(shū)的Designer來(lái)說(shuō)，組件邊界之內的類(lèi)之間的耦合并不是耦合。
3.去除不必要的基于接口編程
眾所周知，Spring是提倡基于接口編程的。
但有些Manager類(lèi)，比如SaleOrderManager ，只有5%的機會(huì )再有另一個(gè)Impl實(shí)現。95%時(shí)間里這兩兄弟站一起，就像C++里的.h和.cpp，徒增維護的繁瑣(經(jīng)常要同步兩個(gè)文件的函數聲明)，和代碼瀏覽跳轉時(shí)的不便(比如從Controler類(lèi)跟蹤到Service類(lèi)時(shí)，只能跳轉到接口類(lèi)的相應函數，還要再按一次復雜的熱鍵才跳轉到實(shí)現類(lèi))
連Martin Flower都說(shuō)，強制每個(gè)類(lèi)都分離接口和實(shí)現是過(guò)猶不及。只在有多個(gè)獨立實(shí)現，或者需要消除對實(shí)現類(lèi)的依賴(lài)時(shí)，才需要分離接口。
3.1 DAO被強制用接口的原因 Spring IOC本身是不會(huì )強制基于接口的，但DAO類(lèi)一般要使用Spring的聲明式事務(wù)機制，而聲明式的事務(wù)機制是使用Spring AOP來(lái)實(shí)現的。Spring AOP的實(shí)現機制包括動(dòng)態(tài)代理和Cgilib2，其中Spring AOP默認使用的Java動(dòng)態(tài)代理是必須基于接口，所以就要求基于接口了。
3.2 解決方法 那就讓Spring AOP改用CGLib2，生成目標類(lèi)的子類(lèi)吧，我們只要指定使用聲明式事務(wù)的FactoryBean使用CGLib的方式來(lái)實(shí)現AOP，就可以不基于接口編程了。
指定的方式為
設置proxyTargetClass為true。如下：
<bean class="org.springframework.transaction.interceptor.TransactionProxyFactoryBean"
id="baseService" abstract="true">
<property name="transactionManager" ref="transactionManager"/>
<property name="proxyTargetClass" value="true"/>
</bean> 又因為這些Service Bean都是單例，效率應該不受影響。
4.總結
對比Appfuse里面的5個(gè)類(lèi)，我的Model層里只有VO作為純數據載體，Manager類(lèi)放商業(yè)方法。有人說(shuō)這樣太簡(jiǎn)單了，但一個(gè)應用，要劃成幾個(gè)JSP，一個(gè)Controller，一個(gè)Manager，一個(gè)VO，對我來(lái)說(shuō)已經(jīng)足夠復雜，再要往上架墻疊屋，恕不奉陪，起碼在我的項目范圍里不需要。(但有很多項目是需要的，神佑世人）
后記：迫于世人的壓力，
SpringSide還是把DAO和Service層分開(kāi)了，但依然堅持不搞那么多接口。
