應用層次結構
應用分層的目的是什麼？復用，解耦，提高**的可讀性，減少**的維護成本。這些目的都很重要，大家也都清楚。我想說的是乙個大家忽略的同時也是最重要的目的，就是減少同事**歸置出錯的概率。這怎麼解釋呢？乙個專案不是一人吃飽全家不餓的情況，都是大家協作完成。由於大家技術能力不大相同，特別是當有很多剛畢業的同事時，良好的層次結構能提供一種約束力減少**歸置出錯的概率，並且在review**的時候，更加簡單輕鬆，通過率更高。因此，以下任何乙個依據都可以做作為分成的必要條件：
1. 復用，解耦，提高**的可讀性，減少**的維護成本
2. 提高**歸置的約束力，減少自己和同伴**歸置出錯的概率
facade：
主要為controller服務
總領本領域的所有service
提供給其他模組的service引用
service：
提供給其他sevice類平行引用，禁止相互引用
主要處理業務邏輯
處理業務聚合後的cache
如果service**量過多，請閱讀下面「值得玩味的service」的內容
其實這樣也不能處理所有情況，更複雜的情況請看下面「值得玩味的service」標題的內容。
inkservice(invoker service)：
遮蔽rpc介面的變化對專案的影響
封裝invoker介面資料、快取invoker介面資料
只處理invoker，invoker介面聚合，cache
能被多個模組的service引用
manager：
只處理db，cache
只能被本模組的service引用
dao：
處理db
invoker：
inte***ce
invokerimpl：
簡單的包裝公司內部rpc介面
remoter：
inte***ce
rmiimpl：
簡單的包裝公司內部rpc介面
component
主要包括乙個模組中service群共同依賴的service方法
只能本模組service引用，輔助service執行去職能
helper：
只做共用資料打包和介面聚合邏輯，不做業務邏輯
只能本模組service、component引用
值得玩味的service
如果service的內容特別多，造成難維護的情況。有兩種選擇可以參考：
如果有必要，對目前的service再進行domian劃分，建立新的service模組；
對目前的service再進行更小的domian劃分，**成多個service。本領域的service變多了也不好維護，並且相互依賴，怎麼辦？用helper和
component輔助service執行其職能，helper和component的具體內容請看層次結構介紹。
**邏輯分解推薦
**分為業務處理邏輯、業務異常處理邏輯、其他異常處理邏輯、資料打包邏輯、資料獲取和儲存邏輯等等
上面的劃分只是個人觀點。有種說法是所有**邏輯都是業務處理邏輯，我覺得概念太過籠統。我細分了一下這些概念，其中「業務處理邏輯」的概念只是業務變更的那段邏輯，這樣做的目的是剝離出真正的業務最關注的**部分。例如，報備樓盤到帶看樓盤的過程中，「業務處理邏輯」的概念只是報備狀態0便變成帶看狀態1。spring注釋規則
controller：@controller用於標註控制層元件（如struts中的action）
service：@service用於標註業務層元件
manager、invokerimpl、rmiimpl：@repository用於標註資料訪問元件
other：@component泛指元件，當元件不好歸類的時候，我們可以使用這個註解進行標註。
在目前的 spring 版本中，這 3 個注釋和 @component 是等效的，但是從注釋類的命名上，很容易看出這 3 個注釋分別和持久層、業務層和控制層（web 層）相對應。雖然目前這3個注釋和 @component 相比沒有什麼新意，但 spring 將在以後的版本中為它們新增特殊的功能。所以，如果 web 應用程式採用了經典的三層分層結構的話，最好在持久層、業務層和控制層分別採用上述註解對分層中的類進行注釋。
抽象domain，劃分service邊界
各層次只做職能當中的事情，禁止跨層呼叫。如果有，請拿上你的案例和我討論！
最大難點：你想不想做，去不去做？問題一
q:把**寫在**才正確？
a:**邏輯見上圖
q:如何抽象domian
a:詳情請參考《大象-think in uml》
q:如何重構**
a:詳情請參考《重構-改善**既有設計》
q:如何避免大量service相互迴圈依賴？
a:目前service只允許迴圈平行引用，當出現相互迴圈依賴的問題時請考慮如下原因：
原因一：service的domian劃分出現了問題，請重新考慮邊界問題；
原因二：可以考慮抽象更加下層service領域，然後相互迴圈依賴的service再引用這個下層service；
如果還有其他原因，請帶上案例來和我討論吧！
domian
全能函式
超過64k的檔案類
長函式體
長函式名
不明其意的命名
命名困難
switch-case/if-else等多個type的問題
介面vs繼承
用多型處理一些問題，想想設計模式
資料類是否是合理的冗餘
盡量簡單，只做一件事
更多警惕請見《重構-改善**既有設計》的第三章，以及書本最後幾頁，以及《程式效能優化》第三章3.5節。
PN結是什麼？PN結有什麼特徵？PN結的應用
pn結學習思維導圖 在看接下來的內容之前，我們先看看本文的思維導圖。首先對pn結的定義及原理進行分析。了解原理之後，來分析學習它的特徵，有了原理特徵當然是要應用了。是不是有點晦澀？學習就是要逐漸理解那些晦澀的定義，好了進入主題。我們首先拿出來一塊矽 鍺 片 本徵半導體 靈光一閃我們就在這個矽片上確定...
向Spring MVC web 進行頁面傳值
當controller元件處理後，需要向jsp傳值時，用下面方法 1.直接使用httpservletrequest和session 2.使用modeandview物件 3.使用modelmap 建模 引數物件 4.使用 modelattribute註解 直接使用httpservletrequest和...
Zend Framework1 應用的目錄結構
zend framework建立的應用有自己獨特的結構，這裡講一下乙個web應用具備的基本目錄結構。大體如下 configs配置檔案存放目錄 controllers控制器 errorcontroller.php indexcontroller.php formsform存放目錄 testform.p...