內容太亂，如果懶得看請只看粗體部分就可以了
springside的一個特點就是manager繼承自DAO，其實這是個名字上的問題。
Java EE一直強調分層架構，在Web部分比較典型的就是前端MVC、中間Business、后面持久化。而Manager對應business，持久化由于實現替換的需求一般使用DAO模式。
先分析一下在輕量化的Java EE下面他們存在的意義：
1、有的人說過在Web項目中Manager和DAO是同意的，尤其是在透明ORM存在下，DAO由于往往是CRUD的實現場所，而Manager卻往往是薄薄的一層門面，很多人就在質疑兩者的合并問題。
可是robbin曾經進行過一個精辟的分析，雖然兩者做的看起來差不多，可是兩者的事務屬性卻不一樣，Manager應該有清晰的事務界限，而DAO不應關心于此。也就是說Manager可能會將幾個DAO方法組合調用，然后封裝在一個事物中。這樣說明確了兩者的一個重要區別，我們也能體會在使用聲明事務的時候有一個分明的事務界限是很有意義的，否則就有可能把Manager中的一個事物拆分，這樣實際上就錯誤了。
2、有些人質疑透明ORM存在的情況下DAO存在的意義，因為透明ORM基本已經隔離了不同數據庫的方言區別。這個也很簡單，Rod大叔分析過。
透明ORM存在的情況下DAO起到了隔離透明ORM與EJB或者JDBC實現的作用，這幾種實現實際上是應該考慮到的。
3、還有一個問題，就是DAO是否應該隱藏透明ORM的API。因為前面說到了DAO起到隔離實現的作用，似乎應該隱藏特定API。可是某大叔也說過，完全隔離不可能，修改底層實現而不修改上層API也不劃算（應該說往往費力不討好），其實就是Rod大叔的思想，我們寧可提供各種support或者template，但是不強求抽象出各種實現。所以
DAO的實現即使依賴于部分Hibernate API也不是錯。
上面純屬貧嘴，知道的朋友們不要嫌棄。
說說Springside的實現。
其實，
實際上Springside使用的就是經典的GenericHibernateDAO+無Manager的實現。這么說在否定前面所說，不過其實這都是文字游戲：D
首先，對于Hibernate為主的實現下，DAO使用Generic是很方便的。Spring的hibernate template受累于向JDK1.4兼容，所以沒有用generic，但是實際上DAO是generic的經典應用。在Hibernate網站上有過討論。現在Springside使用的GenericHibernateDAO已經進化的非常先進了。
Springside實際上有Manager，我說沒有其實是指它的Manager繼承自DAO。看似亂倫，但實際上非常合理。
前面說了Manager與DAO的很大區別在于事物范疇，使用繼承后，兩者之間就可以分離，可以通過Spring的AOP將事物屬性配置在Manager上，也就解決了問題。這應該說也是template模式的標準應用。本來Manager就有很多方法可以通過模板實現，而DAO和Generic就很好地解決了他們之間的模板關系。
我們先看看具體的設計：
以CustomerManager為例，我們看看類簽名：
CustomerManager extends BaseHibernateDao<Customer>
BaseHibernateDao<T> extends AbstractHibernateDao<T>
AbstractHibernateDao<T> extends HibernateDaoSupport三層結構：
第一層AbstractHibernateDao繼承自大家都熟悉的Spring的HibernateDaoSupport，這一層的主要作用是擴展Generic，這樣一方面減少了強行類型轉換的啰嗦，一方面使DoaminClass的信息通過Generic繼承透明聲明。這一層還有一個作用，就是說不管你是否使用Generic，你的應用程序最好也在這里增加一層繼承，作用是在需要的時候你可以在這里擴展DAO模版：D
第二層是BaseHibernateDao。這個其實是springside很自豪的一個地方，可以理解，因為這里真的花了很多的代碼，而且相當精妙。不賣官子，其實
這里主要給DAO擴展了分頁支持，這顯然是異常重要的，大家google一下就知道分頁在Web應用中的重要性了，
基本上你看一個Java Web Framework都會看到它對自己分頁特性的支持方式介紹，或者說分頁的實現風格已經是Java Web Framework實現優劣的一個標準了。應該說，
springsdie的分頁實現來自javaeye上的一個經典的討論，robbin等牛在里面仔細討論了用DetachedCriteria實現分頁查詢，后面引出bug，然后解決，希望沒看過的朋友都看看。（應用Hibernate3的DetachedCriteria實現分頁查詢|http://forum.javaeye.com/viewtopic.php?t=14657&postdays=0&postorder=asc&start=0）
springside的實現是集大成者，考慮到了Criteria（不僅是DetachedCriteria）、HQL、collection.size()幾種不同實現，也考慮到了使用Criteria的時候Order造成的問題（這個在我的Blog中給DetachedCriteria擦屁股那個里面討論過）。
第三層就是具體的Manager，它是用Generic繼承傳遞了DoaminModel的類信息。由于大部分CRUD已經在DAO里面實現了，所以Manager只需要實現一些需要特殊實現的method的就可以了，簡單的應用中Manager里面經常是空空如也。
其中，BaseHibernateDao的實現相對復雜，主要因為里面包裝了分頁實現。大家可以具體看看CriteriaPage和HqlPage兩個類，這是精妙所在。但是在這一層還有個
CriteriaSetup是個比較奇怪的東西，一開始沒太看明白是做什么用的。后來問了百衣，他說這是為了解決search問題提供的，從jsp傳遞過來的東西在Controller層可以通過util（
這里springside很CoC，它把search_開頭的東西自動作為“=”的查詢條件傳給Manager，但目前的缺陷在于只能默認處理“=”，其它方式需要擴展）處理查詢條件傳給Manager，但是這個東西設計得有點怪，白衣也對它不滿意，說在Springside 2.0里面要重構掉，但還沒有什么好的想法，大家又建議可以提給他。
我認為傳遞查詢信息大概需要這樣的設計：
1、在Controller里面不暴露hibernate API，但是能夠順利將參數傳遞到Manager。
2、Manager直接傳遞，或者將這些參數轉換為Hibernate API后再傳遞，因為這正是manager需要負責的商業邏輯之一。
3、DAO里面最好不要做那么多轉換，畢竟它是持久層。
當然，目前符合這個要求，只是限定于Map是二元容器，不能存3元的查詢條件（key、value、type）。所以可能下一步會補足。
分析到這里，springside的DAO的結構大概就是這樣的。
感覺這和我們Team上個項目的結構很象（不好意思，沒說有springside那么好），有一點區別。
由于Manager繼承自DAO，我們讓DAO多了很多方法，主要就是想提供方便。尤其是
<T>?T?loadById(Class<T>?persistenceClass,?Serializable?id);
<T>?T?loadByProperty(Class<T>?persistenceClass,?String?propertyName,?Object?value);
<T>?List<T>listAll(Class<T>?persistenceClass);
<T>?List<T>listByProperty(Class<T>?persistenceClass,?String?propertyName,?Object?value);
<T>?List<T>listAllOrderBy(Class<T>?persistenceClas,?boolean?isAsc,?String?orderByPropertyName);
這些東西經常用到，如果使用了會減少了很多時候遇到的Manager里面注入其他Domain的DAO，卻只是為了load或者listAll的問題（同時用generic）：D今天有點別的事，先說到這里，好好想想，看有什么問題過兩天在說說。
這Blog太流水賬，太空洞，大家見諒。