來自:http://www.javaeye.com/topic/17518?page=1
問題是我覺得rich domain object 和domain Dao雙向依賴的關系我也很不喜歡。我覺得那么就像現在那么樣，thin domain object，外加Dao層和Service層，單向依賴，分層很清楚，要么就向rails那樣，就是一個model，管你dao還是service，全 部都在model里面。
赫赫，請問，沒有domain model ,何來dao ，何來敲擊鍵盤而來的代碼？
dao依賴domain model是很理所當然的。 不過讓domain model依賴于dao，確實很拗口，所以dao肯定需要一個接口，domain model依賴于dao的接口也是很合理的。這里的關鍵在于：
把DAO已經published的接口作為整個領域模型比較核心的一部分。 如果設計比較好的ORM 關聯可能會把引入query 導致的雙向依賴的危險減至最小，不會因為DAO接口實現的失敗導致整個領域模型的錯誤，而把這種錯誤轉變為領域模型關聯關系的設計錯誤。

這里有個publish接口容易導致被誤用的危險，DAO接口如果是領域模型提出的請求實現，那么這個設計就會很冒風險，因為如果一旦你的DAO接 口publish了，你就要冒著別的正在寫domain model的開發人員會耦合于你的接口，一旦你的接口publish了，改動就非常困難了，而且如果一旦發現因為需求分析不夠導致的DAO接口邏輯有問 題，那么這個將是非常痛苦的重構/修改過程。
所以關鍵在于讓合理的關聯代替復雜的查詢。

說到接口，順便說說對滿天飛的interface的反感，我以前就是那樣滿天飛的，先在感覺飛的太高了。

接口其實就等同于代碼隱藏，說句不好聽的話就是代碼私有化。 我發布一個接口，加上一些比較清晰的說明。 調用著一般都會只看接口說明感覺合適就直接IOC進來用了，久而久之就有可能被誤用接口的危險。 如果沒有接口，依賴代碼就是文檔的和相互可以修改的原則，那么大家都可以直入對方的正體，看一下對方代碼的具體實現邏輯，有問題可以直接提出來探討，這樣 就減少了程序風險，而且也省去了來來回回反反復復修改interface 和實現的麻煩。
接口就如同是一個蓋子，蓋住了很多東西，然而在代碼極度共享和互改的環境中，還是少用為妙。

我的觀點是一個重要的接口都應該提供一個抽象類來實現基本的骨架!這樣當你的接口改動時只影響你的抽象類。而對實現接口的繼承抽象類的子類沒有影響。 其實接口只是定義mixin(混合類型)的理想選擇(java中接口才允許多繼承)， 例如：一個教練本身也是球員。那么我們可以定義一個mixin接口，組合一些新的方法讓實現這個mixin的抽象類不僅具有Train和Play的職責， 還有組合產生的特性。
一個缺點：不支持分布式部署。無法把一個bean給fail over或者re-deploy。
實際上，所有輕量級ioc容器真用起來都沒什么用處，因為它們都無法應付分布式的需求。（jboss mc的作者跟我說的）

呵呵？誰有分布式的需求？

spring不是支持集群了嗎？分布式就用不著了吧

有一個收費的T字頭的方案能幫助spring實現分布式吧，沒有免費的實現是挺麻煩的。

我們的做法是在5臺tomcat服務器前面放一臺四層交換機之類的硬件，這樣，相同的ip來訪問時會被指派到同一臺tomcat,因此不需要http session共享，也能達到類似的分布式效果，還節約了session共享的消耗。

一直覺得interface就是C++里的.h 頭文件，好不容易java里不需要.h,脫了苦海，現在大家又爭先恐后再入火坑。

其實如果把interface用于動態proxy, cglib已經提供了解決方案，spring的OAOP,測試時的easyMock,都有cglib實現，性能比基于interface proxy的更高一點點。

如果是代碼設計方面的，一定要看清楚實際情況再決定是否抽象interface。我覺得interface在代碼設計方面最主要的應用其實是多重繼承吧和firebody說的蓋子功能吧。

所以springside里只有幾個用到多重繼承和webservice蓋子的時候才用了interface. 比如dao, appfuse等sample為了演示多種dao方案才用interface阿，我們沒事又不會換orm方案的，忙活這個接口沒意義呀。