最近要開始一個新項目，上一個項目采用貧血的多層構架，感覺IDao，IService大多數(shù)都無用，雖然有IDE輔助但是仍然很痛苦，想請教一下大家在實踐中是怎么使用多層構架的。DAO層是否有必要存在？畢竟對于一個電商網站你不太可能將數(shù)據(jù)序列化到文件吧，而且采用Redis等內存數(shù)據(jù)庫也要特殊處理吧，不會直接替換一個DAO實現(xiàn)了事吧。如果只是作為關系數(shù)據(jù)庫的封裝，ORM也已經封裝的不錯了，Java中的常用的ORM也就Hibernate和ibatis一般根據(jù)人員學習成本相比中途也不會無痛切換吧。Service層什么情況下才需要有不同的實現(xiàn)類？Service不過是作為一些代理和跨dao,entity的調用，直接替換不同DAO實現(xiàn)來更換持久化方案我能理解，但是什么情況下才需要替換Service的具體實現(xiàn)呢？開始時接口是否有必要存在？開始就采用接口基本就要兩個文件來回跳來跳去，如果開始時候就直接使用實現(xiàn)類直到需要時在引入接口成本是否會很高？畢竟只是聲明類型變了，業(yè)務邏輯沒變。（該問題已有同學回答，參見每一個類都應該有一個接口嗎？）引用別人對貧血模型和充血模型的總結(沒記錯的話應該是javaeye的robbin總結的)：對于Java來說，更加適合采用貧血的模型，Java比較適合于把一個復雜的業(yè)務邏輯分離到n個小對象中去，每個小對象描述單一的職責，n個對象 互相協(xié)作來表達一個復雜的業(yè)務邏輯，這n個對象之間的依賴和協(xié)作需要通過外部的容器例如IoC來顯式的管理。但對于每個具體的對象來說，他們毫無疑問是貧 血的。這種貧血的模型好處是：1、每個貧血對象職責單一，所以模塊解藕程度很高，有利于錯誤的隔離。2、非常重要的是，這種模型非常適合于軟件外包和大規(guī)模軟件團隊的協(xié)作。每個編程個體只需要負責單一職責的小對象模塊編寫，不會互相影響。貧血模型的壞處是：1、由于對象狀態(tài)和行為分離，所以一個完整的業(yè)務邏輯的描述不能夠在一個類當中完成，而是一組互相協(xié)作的類共同完成的。因此可復用的顆粒度比較 小，代碼量膨脹的很厲害，最重要的是業(yè)務邏輯的描述能力比較差，一個稍微復雜的業(yè)務邏輯，就需要太多類和太多代碼去表達(針對我們假定的這個簡單的工時管 理系統(tǒng)的業(yè)務邏輯實現(xiàn)，ruby使用了50行代碼，但Java至少要上千行代碼)。2、對象協(xié)作依賴于外部容器的組裝，因此裸寫代碼是不可能的了，必須借助于外部的IoC容器。對于Ruby來說，更加適合充血模型。因為ruby語言的表達能力非常強大，現(xiàn)在用ruby做企業(yè)應用的DSL是一個很熱門的領域，DSL說白了就是用來描述某個行業(yè)業(yè)務邏輯的專用語言。充血模型的好處是：1、對象自洽程度很高，表達能力很強，因此非常適合于復雜的企業(yè)業(yè)務邏輯的實現(xiàn)，以及可復用程度比較高。2、不必依賴外部容器的組裝，所以RoR沒有IoC的概念。充血模型的壞處是：1、對象高度自洽的結果是不利于大規(guī)模團隊分工協(xié)作。一個編程個體至少要完成一個完整業(yè)務邏輯的功能。對于單個完整業(yè)務邏輯，無法再細分下去了。2、隨著業(yè)務邏輯的變動，領域模型可能會處于比較頻繁的變動狀態(tài)中，領域模型不夠穩(wěn)定也會帶來web層代碼頻繁變動。為什么Java只適合貧血模型？有沒有什么場景下可以允許所有業(yè)務邏輯和持久化全部揉在Model中。