解析三層架構1
隨着分層設計的進行,對分層逐漸有了更深的瞭解.準備利用3篇文章,深度的分析一下分層設計.
我這裏的題目之所以叫三層架構,不一定代表着系統就是三層.古語中三爲多.這裏的三層也可能是
四層,五層 或者更多層.
爲什麼要分層:
這是一個很基礎的問題.很多的人都在討論爲什麼分層.分層到底有哪些好處.在什麼樣的情況下分層
其實網上已近有很多這樣的解釋,首先我總結一下他們的觀點
1.方便團隊分工
以前的按功能模塊一般是幾個人將項目的功能模塊一分，每個人從操作數據庫、完成業務邏輯到實現界面都要獨自完成，當然數據庫的設計可以由一個人完成，這樣的開發顯然有弊病，首先每個開發人都需要掌握大部分技術，還要有很強的業務邏輯的理解能力，其次每個人的開發習慣都不同，形成的代碼繁雜可讀性差，最後後期的完善、維護都會造成麻煩。相信很多人都會理解這樣的痛苦經歷，多層開發就能解決上面的問題麼？如果是一個合理的多層開發模式是完全可以解決的。
將軟件開發分層，其實可以簡單的理解爲工種分層、規範代碼，基本可以將工作分爲界面設計人員、業務實現人員、數據庫設計人員。界面設計人員的工作就是畫程序界面然後將信息提交給業務層，不需要考慮業務層的邏輯關係，業務實現人員的工作是處理界面提交的數據請求完成邏輯流程，再結合數據訪問層，不用考慮界面設計的樣式、風格，也不用考慮數據庫的格式，數據訪問層一般是設計完善的架構系統，基本不需要人員工作，主要是屏蔽掉數據庫間的差異，爲業務層提供便捷的操作功能，數據庫設計人員就是設計、規劃數據庫。很顯然一個團隊採用多層開發就可以合理的分配人員工作，將每個人放置到適合的崗位上，而主要的技術人員集中在關鍵部位的開發工作，重複簡單的勞動，如畫界面就可以安排給新手來完成。
2.其他特點
還有以下的一些特點：
規範代碼：在開發過程中可以將每層的代碼進行規範，固定開發語言的風格；
忽略數據庫差異：好的數據訪問層可以將數據庫的差異完全屏蔽，對開發人員只是做相同的數據操作工作，甚至可以快速進行數據庫轉換；
上述兩個觀點基本上是代表了網上的主流觀點.他們也基本把分層的優點說的差不多了
但是這個真的是分層的原因嗎?我認爲他們只是說了分層的表面而已.爲什麼要分層這個問題他們依然沒有說明白.
就像是我問你人類爲什麼要吃飯,你回答我吃飯能使人身體好,有能量.咋一聽起來似乎沒有問題.但是總覺得有點彆扭.其實根本上說是:人類需要吃飯.換句話說就是如果人不吃飯能身體好,有能量,我相信人類肯定是不會去吃飯的.
這個就像是軟件設計的分層一樣.很簡單:大型企業開發需要分層.而分層絕對也是爲了解決企業開發而來的.你絕對不能在單片機,智能電器開發中用分層.這個就有點張冠李戴了.
言歸正傳,我來說說爲什麼 要分層.瞭解一件事物,比如瞭解他的歷史.我在查閱了很多資料以後,對分層的歷史有了一點眉目了(網上這個資料真的很少,甚至沒有,可能不太準確,希望大家指正).
1996年SUN公司退出了java,其"一次開發,多次應用",與平臺無關的開發讓衆多的企業紛紛推出基於java標準版的API,java的良好性能讓java的企業開發呈現爆炸式增長.
而後爲了解決各企業API的兼容性.sun聯合IBM,Oracle,BEA推出了強大的j2EE,也就是java的企業版.這樣基於java的企業開發才進入了飛躍發展時代.也就是這個時代讓企業分層開發逐步走向成熟.
補充:j2EE只是一個標準,不是eclipse,也不是myeclipse
微軟在2000年推出了它的.net開發平臺,真正的走向企業跨平臺開發.
那麼爲什麼企業那麼喜歡java呢?除了它跨平臺,安全以外.重要的一個原因就是java專門爲企業開發提供了多層分佈式企業應用模型.
下面我們來說一下對於企業應用模型的理解:
在企業中,公司有明確的分工和部門,這些部門很可能不在同一個地區.每一個部門用到的系統一般是不同的.但是我們又希望每一個部門的信息統一起來管理,便於管理層管理.同時,企業的數據對安全性要求一般是很高的.不希望系統每一個部分都部署在每一個員工的PC上.這樣顯然不是安全的.
所以,我們解決的辦法就是把系統拆分開來,
在J2EE中，應用邏輯按功能不同可以劃分爲不同類型的組件，各組件根據它們所在的層分佈在不同的機器上，共同組成一個基於組件的分佈式系統。
這樣,系統的安全性,可靠性大大的提高,充分發揮了分層的作用.
也就是說,分層可以把各層部署在不同的地方.在一層中,顯然是不可能出現分佈式系統的.
上面幾點就是對於分層的原因的解析.其中還是建議大家,想了解一種技術.最好的方法就是去看看這種技術的歷史.不要人云亦云,回顧過去,才能更好的瞭解現在,展望未來.
接下篇:解析三層架構(2)----分層到底分出了什麼
解析三層架構(3)----實體類與面向對象
本文來自CSDN博客，轉載請標明出處：http://blog.csdn.net/lsh6688/archive/2011/05/10/6408215.aspx