可以用這樣的思想：
最初的應用是單機，數(shù)據(jù)和功能都放在一臺機器上。隨著應用向工作組模式發(fā)展中，人們迫切需要
調用彼此的數(shù)據(jù)，也調用彼此的功能，這樣人們就不用重復錄入數(shù)據(jù)，程序員也不須重復寫
功能。數(shù)據(jù)和功能先共享哪一部分？雖然說通過功能就可以把數(shù)取出來，數(shù)據(jù)在功能屏蔽之下，似乎
無須共享出來，但是功能是基于數(shù)據(jù)的，功能共享出來了，單獨放在一臺機器上讓大家使用，但是這個功能
需要的數(shù)據(jù)在A，B，C，D...上分布著，到底是誰？所以必須先共享數(shù)據(jù)。所以才有了C/S模式
一邊是數(shù)據(jù)庫，大家都對著這臺機器訪問數(shù)據(jù)，一邊是大量的客戶端，程序都在每臺機器上。
隨著部門間計算模式的發(fā)展，一個系統(tǒng)想存取另一個系統(tǒng)的數(shù)據(jù)，但是表結構已經(jīng)很復雜了，
業(yè)務邏輯也已經(jīng)錯綜復雜了，你已經(jīng)不可能獨自寫一段程序存取另一個系統(tǒng)的數(shù)據(jù)。這時只能合作，
讓對方寫一個功能，給你開放出來，你一調用就能得到你想要的結果。但是這個功能寫好是該放到哪臺機器上嗎？
肯定不可能放在每個客戶端上，又需要單獨放在一個機器上，于是C/S/S產(chǎn)生了
這是一個歷史，你就明白了三層該放什么東西。
當然也順便，就是另一些系統(tǒng)不調用的功能也放在了這個公共組件服務器上，來減少數(shù)據(jù)庫連接
雖然有的文章上說這樣可以減少更換程序的成本，這點倒不敢茍同，因為從實際開發(fā)中，如果客戶端是GUI的，
你的很多改動會和GUI改變有關，你還得更新。如果你客戶端是WEB，你還必須是三層，因為你客戶端什么都沒有

至于劃分數(shù)據(jù)層，業(yè)務邏輯層只是為了引導你面向對象思考。說是為了更容易的修改，而不影響另一層，這個也是
比較困難，因為往往客戶要求多顯示一些東西或少顯示一些東西，可以這樣查，可以那樣查，所以
往往數(shù)據(jù)層的SQL語句老變化，而且大多不能在原SQL上改，因為參數(shù)，字段或許都不一樣，你改了，客戶段的取數(shù)就很容易出錯，
你也不敢保證它會在什么功能中被公用到，所以往往是又增加一個新SQL，和原SQL看起來90%一樣，但又不完全一樣。
客戶端界面也老變，有時業(yè)務校驗規(guī)則也不一樣，業(yè)務處理方式也不一樣，所以每層都需要改變

往往一個數(shù)據(jù)對象由兩三張關系數(shù)據(jù)表組成，
在數(shù)據(jù)層表現(xiàn)為數(shù)據(jù)對象，但是由于業(yè)務處理的重點不一樣，也為了速度考慮，取最必要的字段，
所以在這個數(shù)據(jù)對象中有各種各樣的SQL，而不是一個SQL，但是每個SQL都是反映了這個數(shù)據(jù)對象的一個方面
然后寫一些函數(shù)，專門針對這些數(shù)據(jù)對象做業(yè)務處理，還有一些函數(shù)專門負責數(shù)據(jù)校驗，如不可為空，主鍵重復，類型出錯等

在業(yè)務邏輯層分出兩枝，一枝是業(yè)務邏輯規(guī)則校驗，在其中也調用著數(shù)據(jù)層的數(shù)據(jù)校驗規(guī)則，
另一枝是業(yè)務處理，就是調用數(shù)據(jù)層的各個函數(shù)來組合完成一件事，形成一個流程

總結一下，SQL一般都寫在數(shù)據(jù)層，這是很自然的，業(yè)務邏輯層就是組合功能。不管數(shù)據(jù)層的函數(shù)
還是業(yè)務邏輯層的數(shù)據(jù)都和業(yè)務相關，對于數(shù)據(jù)層與業(yè)務無關的說法，在實際中行不通，因為在模型上
說，我們寫在數(shù)據(jù)層上的那些接口方法應該是單獨又分出一層，叫真正的業(yè)務邏輯層，而我這里寫的業(yè)務
邏輯層，模型中叫Facade，就是為了簡化客戶端調用而做的外殼。但個人認為，模型中單分出一層意義不大，
因為每層都需要修改，少一層就好修改一些。而且純粹的面向對象系統(tǒng)在世界上也從來沒有存在過，如果
存在，那必定是一個理論家的東西，而不能實用，就象在實際中我們在設計關系型數(shù)據(jù)庫時先三范式，后為了簡化
編程和提供速度而反三范式。
客戶端也不是多個功能放一個PAS文件中。因為客戶往往要求功能組合。如A要和B功能放在一個界面，
B和C要拆開，所以客戶端也是界面和數(shù)據(jù)操作和數(shù)據(jù)顯示分開，為了在界面上看到的是多個功能在一起
但實際中卻各不混雜，這是個功能模塊劃分，不是層次劃分。如果從界面觀點來看，是層次問題，因為界面和功能算兩個層次

不要拘泥于理論，也不要放棄理論埋頭編程，而是互相借鑒前進，目的就是兩個，為了業(yè)務處理需要，
為了我們好維護程序。

再看看我開頭講的歷史，你會發(fā)現(xiàn)，歷史就是為了這兩個目的而變化

轉載于:https://www.cnblogs.com/coollzh/archive/2004/04/03/5067.html

總結

以上是生活随笔為你收集整理的特老的文章：三层应该怎么划分。不知大家还有用否的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內容還不錯，歡迎將生活随笔推薦給好友。