當開發人員在以前的兩層結構中痛苦煎熬了很長壹段時間，突然看到了三層結構的解決方案的時候，壹般會有終於找到了救世主的感覺。但是這種感覺往往會導致掉到另外壹個同樣恐怖的陷阱“過度設計”中。在我以前曾經供職的壹家公司，以前都是把SQL語句直接寫在ASPX頁面的，後來在讀到了壹些關於多層結構方面的資料之後，壹下子又把整個系統分成了：表現層（ASPX）、接口外觀層（IF），業務外觀層（BF），數據訪問外觀層（DAF），數據訪問層（DA）和數據訪問組件（SQLHelper）。但是我並沒有吸取教訓，導致後來也犯了同樣的錯誤。犯錯誤的原因有很多，不過主要是因為沒有壹個比較明確的如何分層的指導性原則。假如說我們分層的原則是為了抽象邏輯，分三層的原因是要讓業務邏輯和界面及數據庫解除耦合，那麽如果按照這個分層原則，我把邏輯重新歸類更加細的分為四層、五層、六層行不行呢？如果不行，那是什麽原因不行呢？在沒有正確的原則指導下，分層技巧很容易被濫用，導致分出許多沒有必要的層出來。無端的增加了開發和維護成本，以及更重要的是增加了重構的代價，降低了團隊的敏捷能力。面向對象架構設計大師Martin Fowler在介紹如何設計分布式系統的時候曾說過：分布式系統的設計原則的第壹條是，不要使用分布式。他的意思當然不是說要絕對禁止使用分布式設計，而是勸導人們盡量把問題簡單化。能不分布式設計的，就不要分布式設計。我套用他的這句話提出我對分層的感受就是：多層結構系統的設計原則第壹條是，不要使用多層結構。當然我的意思也並不是說層數越少就越好，而是希望妳能清醒的認識到增加層數會增加結構的復雜性，不要輕易的作出分層的決定，壹定要到感覺必須要增加壹層才能解決問題的時候，再來決定增加壹層。過多的層次除了會給系統帶來不必要的復雜性外，還會影響妳的系統結構設計。如果妳打算采用面向對象的領域模型來設計系統的話，在業務系統內的分層會給面向對象系統的設計帶來很多麻煩，會很容易走回到事務腳本的老路上去。請看結構圖
總結壹下：1,建立壹個完全面向對象建模的領域模型層，讓這個層盡量處理多的業務邏輯。其它層盡可能的薄壹點，把業務邏輯都轉移到領域模型層中。2,UI盡可能和領域模型貼近壹點，中間不要經過太多中轉，物理邊界也盡可能的少。3,業務對象只能有壹套，也就是領域模型。只要出了領域模型層，外面全部是零散數據，沒有對象的概念。4只有在領域模型層才可以處理對象。如果壹定要分布式。全部用簡單數據類型通過接口訪問領域模型。 這個分層結構其實是經歷了多次精簡完成的，所有的感觸都歸結為壹句話：不要過度設計，簡單就是美。補充:請看清楚上面的解釋,如果程序允許的話100層也可以掉用.由於編程語言的不同,可以調用的層數不同.比如:Visual FoxPro主要技術性能 1.程序文件與過程文件技術性能· 源程序文件中程序行的最大數 系統沒有限制受可用內存的限制· 編譯後程序的最大容量 為64KB· 過程文件中包含過程的最大數 系統沒有限制受可用內存的限制· DO調用的嵌套層數的最大值 為128層· READ嵌套層次的最大層數 為5層· 結構化程序設計命令嵌套的最大層數 為384層· 函數調用時傳遞的參數個數最多 為27個· 事務處理的最大數 為5件沒有依據或原則能明確規定或建議:"嵌套應該小於5層".沒有這樣的規定.
上一篇:初學Java編程需要了解的學習路線？下一篇:phpcms怎麽在線編輯模板phpcms在線編輯模板保存後報錯