分層開發思想與小籠包

　　早上吃早點的時候，突發靈感，結合吃的小籠包和日常的開發經驗來說一下分層的應用。 

　　首先，談一下什麼是三層架構，所謂的三層開發就是將整個業務應用劃分為表示層－業務邏輯層―資料訪問層－資料庫等，有的還要細一些，明確地將客戶端的表示層、業務邏輯訪問、和資料訪問及資料庫訪問劃分出來，十分有利於系統的開發，維護、部署和擴充套件。 

　　軟體要分層，其實總結一句話，是為了實現“高內聚、低耦合”。採用“分而治之”的思想，把問題劃分開來各個解決，易於控制，易於延展，易於分配資源。  

　　這種三層結構有什麼優勢呢？  

　　1. 通過將整個系統分為不同的邏輯塊，大大降低了應用系統開發和維護的成本。 

　　三層結構將表示部分和業務邏輯部分按照客戶層和應用伺服器相分離，客戶端和應用伺服器、應用伺服器和資料庫伺服器之間的通訊以及異構平臺之間的資料交換等都可以通過中介軟體或者相關程式來實現。當資料庫或者應用伺服器的業務邏輯改變時，客戶端並不需要改變，反之亦然，從而大大提高了系統模組的複用性，縮短了開發週期，降低了維護費用。 

　　趣味理解： 

　　假設飯店這樣來做小籠包：  

　　一層蒸餃，  

　　一層肉包，      

　　一層素包。  

　　首先這種方式我們可以讓做包子的分成不同的小組，來負責做不同的包子。當做好了每一種包子，他們可以很方便的知道，該放到哪個籠裡，不至於挨個去檢視該放在哪裡，我們也很容易地將籠屜放到火上面去，而不會影響其他籠的加熱。當我們要吃肉包或蒸餃時，我們也很容易就能找到我們所需要的，非常節省時間和體力。把肉包或蒸餃拿走或者增加，並不影響素包的加熱。  

　　如果我們把這些都放在一個大籠裡，你覺得會怎麼樣？會不會很亂，維護起來很浪費時間，不但找起來麻煩，而其每次揭開鍋都會對其他的有影響。   

　　2. 將資料訪問和邏輯操作都集中到元件中，增強了系統的複用性。  

　　如：將資料訪問集中到資料訪問層的元件中，從而減少了應用程式中的重複程式碼，每個需要訪問資料庫、表的窗體都使用相同的元件。  

　　如：一些共性的邏輯操作都集中封裝在邏輯層的元件中，每一個使用該方法的操作，可以共享來訪問該元件。  

　　趣味理解：  

　　簡單的理解，籠屜本身就是一個重用的例子，如果我們使用一次性的籠(像一次性筷子一樣理解)，會浪費多少人工來做啊(重複編寫麻煩)，並且會有很大的資源浪費(程式碼冗餘)，最後還要進行垃圾處理(後期維護)。並且，如果籠屜和爐火的鍋按一種規範和標準（介面）來做，這樣的籠屜不但可以在這裡用，也可以拿到別的地方用。（雖然這樣理解不太確切，簡單的這樣理解好了） 

　　3. 系統的擴充套件性大大增強。 

　　模組化使得系統很容易在縱向和水平兩個方向擴充：一方面可以將系統升級為更大、更有力的平臺，同時也可以適當增加規模來增強系統的網路應用。由於擺脫了系統同構性的限制，使得分佈資料處理成為可能。在擴充或修改功能時，基本不會破壞原有結構的穩定性。  

　　趣味理解： 

　　隨著顧客的需要，我們現在需要增加新品種，如蒸饅頭，蒸地瓜，那麼直接可以增加一層籠就是了，對其他籠不會有什麼影響。   

　　三層結構在營造企業競爭優勢中的作用主要體現在模組化設計使得使用者在現有結構的基礎上實現了系統擴充套件，從而提高企業資訊化的速度和業務水平；同時三層結構中中介軟體的出現使得使用者可以直接從市場上選擇合適的產品來構建系統，大大降低了開發週期和開發費用。   

　　但分層結構也有缺點也不是越多越好，那樣管理很多層會比較麻煩，執行效率可能比較低。所以，一個具備良好層次結構的系統，其層的數目要恰到好處才行。

相關文件：三層架構和養豬