轉自http://fei-6666.iteye.com/blog/446247，記錄下來html
一，Service->DAO，只能在Service中注入DAO。
二，DAO只能操做但表數據，跨表操做放在Service中，Service儘可能複用DAO，只有一張表產生的業務放入DAO中。
三，事務操做，放在一個DAO中。
四，若是有更大Service的之間的複雜調用，考慮在service上再加Facade層(Components組件)。
五，多考慮這部分代碼放在哪裏，多裏利用上下分層，增長代碼可讀性，提升代碼複用率。
服務層處理業務邏輯，DAO封裝Entity對象，Action做爲Controller處理分發。
業務邏輯是最容易變化的地方，當業務改變時，只增長修改相應的代碼便可。真正享受分層帶來的益處。
文章出處：http://www.diybl.com/course/3_program/java/javaxl/2008620/126932.html
J2EE分層設計是Java企業應用的最基本的設計思想。
從最常規的分層結構來講，系統層次從上到下依次爲：
表現層：主要是客戶端的展現。
服務層：直接爲客戶端提供的服務或功能。也是系統所能對外提供的功能。
領域層：系統內的領域活動。
DAO層：數據訪問對象，經過領域實體對象來操做數據庫。
其中有些指導原則：
一、上層老是依賴其下層，依賴關係不跨層。
二、表現成除外，同一層之間方法不容許相互調用。這是實際開發中一些開發者容易範的錯誤！若是真是同一層之間存在方法調用，須要注意，這些調用都是一些上層不可見方法，好比一些工具方法等。
三、一切從服務層出發，從系統須要提供的功能進行分析，肯定Service接口中的方法。而不是從數據庫的表出發，建立DAO，再創Domain，而後Service，這其實是對系統分層的誤解。
四、系統最核心的設計就是將系統中的實體劃分爲領域模型。在此基礎上設計數據的DAO層，並將這些活動暴露給服務層，服務層的實現依賴於領域活動。
五、每一個接口的職責範圍明確有界。
在我所作的系統中，經常看到一些糟糕的編碼：系統設計從表開始，一個表對應一個DAO，一個DAO對應一個domain，一個Domain對應一個Service，實際上Service的接口和DAO的接口基本上徹底同樣！致使Service的接口方法超多！到了表現層，前臺程序員在寫Action的時候，Action中反覆的調用Service方法，代碼不堪入目。
正確的設計應該是，一個領域活動會聚合對應一個或一組DAO，來完成一個領域活動。而一個服務可能包含兩個領域活動，好比一個轉帳的業務，對應兩個領域活動。兩個賬戶的金額分別發生變化，須要操做一組領域活動，而每一個活動須要操做不少表（調用多個DAO）。 事務的控制咱們能夠放到Service層。
目前，愈來愈多的架構師喜歡領域模型驅動設計，針對系統的領域模型建模，而後上層直接是Service，Service下面就是領域活動層Activity，從而去掉了DAO層，這樣作的優勢是系統設計思路更清晰，目標更明確。能夠避免上面所說的一個表對應一個DAO、Service的狀況。
但缺點是當領域活動發生變化的時候，會引發領域活動層代碼的變化。而且，當要更換持久化框架或者技術時候，領域活動要從新實現。
但綜合考慮起來，這樣帶來的優勢也不少，而實際上更換數據庫和持久化框架的狀況不多，所以這樣的設計也是有其合理性一面的。這樣作其實是將原來的DAO和Domain層合併爲一個Activity.但上層的設計思路仍是一致的。
其實Service層的設計也很講究，其中就是要控制Service的數量，從Service層往下，接口數量逐層增長。一般將一個模塊的服務都集中到一個Service中來處理。
每層中的每一個接口都應該關注的是本身的那一塊，而不是吃着碗裏看着鍋裏，牛槽伸出個狗舌頭，最典型的例子就是一個DAO中胡亂操道別的表。這種凌亂的實現只會置項目經理與死地。也會爲軟件的維護帶來很大代價。
筆者曾遇到這樣的團隊，缺少對整個項目的總體設計，一個表一個DAO，對應一個Service，系統也不大，三四十張表，可是性能至關地下，常常down機。
最終發現，失敗不是開源框架和數據庫以及應用服務器和硬件配置的錯，根源在於拙劣的設計致使。
但願之後你們在作項目的時候能注意點 java