初窺三層架構

即使到目前為止，我對三層的理解也是模糊的，發表下自己的拙見，希望大家指正。

不是所有的程式都是適合使用三層的！

很多出循著都會存在這樣的誤區，我學了半天三層發現對於我所寫的代碼沒有什麼用，反而讓代碼更複雜，費時費力，所以，我在論壇上看到不少關於三層的評價是“取之無味，棄之可惜”、“用了一段時間，感覺特別麻煩，就不用了”。其實，這並不是三層的問題，而是程式本身的問題，說一個我們平時最常見的問題，來說一下三層。

這是一個飯店的系統，和三層有著異曲同工之妙，這張圖在很多關於三層的學習中都存在，其實這個例子不僅能充分解釋三層的關係，更能說明三層的使用範圍，同樣是為客戶提供服務的，為什麼不舉路邊的小吃攤那樣的例子？因為它不符合三層的特點，對了，其實，我們平時所寫的程式中，很多就是路邊的小吃攤，服務員，廚師，採購員都是同一個人，所有也就無法分出展示層，商務邏輯層，資料訪問層了，所以，三層一般都用於大型的項目，需要多人多組開發的，組與組之間互不影響。再說我們學三層的經曆，其實我剛開始學也是這種感覺，感覺三層沒什麼用，其實，原因就在於，我提供的是路邊的小吃，也就是，我所使用寫三層的程式是很小的，但是，我卻請了服務員給我賣，請了廚師專門做飯，請了採購員去採購，所以，本來是小本經營，一下子就賠了大本，但是，我們初學三層又不可能使用多麼龐大的程式，所以，擺正心態很重要。畢竟，我們是初學者。

三層架構之間的影響問題。

這是我在一個論壇裡看到的人們關於三層的一段對話。

其中一個人認為三層是雞肋，另一個人認為三層是件非常好的東西，他們關於三層之間的改動問題的討論。

以下是我理解的三層之間的修改關係。

首先，在開發中，如果不使用三層（當然，有時候不只是三層，可能是多層，這裡以三層為例），而程式是幾個人一起開發，那麼他們這幾個人之間的耦合性就會非常大，比如，其中一人有事，那麼另外兩個人就無法工作，或者，某一人只能另一個人完成時他才能工作的情況。而使用三層，開發人員的耦合度降低，不會因為一個人請假而另外兩個人而無法工作的情況。

其次，是使用中，比如我們開發一個系統，所用的資料庫是SQL SERVER2005，但是情況需要，另外一家公司也需要開發一個類似的系統，他們所使用的系統是ORACLE,那麼，不使用三層的程式就需要改動大量的代碼，而使用三層，只需要改動DLL就可以了，層與層之間是互不影響的。

還有，三層的解耦合讓系統更安全，即展示層與資料訪問層中間加了一個商務邏輯層，這樣就使得使用者無法直接存取資料訪問層，使資料更安全，這也是分三層後層與層之間的影響減少的一個表現。

三層更容易使代碼複用

因為三層之間的耦合性比較弱，所以，他們可以大大提高代碼之間的複用，所以，從長遠角度來看，雖然三層在寫的過程中比不分層多花費時間，但是最終還是省時省力的。

其實，沒有什麼體系是萬能的，主要是看適合和不適合，就像我們不可能讓一個路邊小吃去請服務員，廚師，採購員，更不可能讓一個大型飯店一個人去承擔服務，廚師，採購的職責，合適才是最關鍵的。