你了解.Net 分層架構嗎？

 許多朋友言“分層”則必稱“DAL”、“BLL”、“表示層”等概念，殊不知“DAL”的內 部還有“DataSource架構模式”、“t-Relational Behavioral 模式”、“t-RelationalStructural模式”等方面，而其中每個方面下下又有諸多具體模式，如“Data Source 架構模式”又有“TableDataGateway”、“Row DataGateway”、“AcitiveRecord”等等。再說“BLL”，大家都知道“BLL”是“業務邏輯層”，可是什么是“業務邏 輯”？“BLL”又可以構建為“Transactiont”、“DomainModel”、“TableModule”三種模式，各是什么意思？另外，分 層也不僅只有“數據訪問層”+“業務邏輯層”+“表示層”這一種分法，諸如“服務層”、“持久化層”、“應用控制層”的概念朋友們是否真的熟悉呢?

洞悉分層的本質

    我們可以討論如何分層，可以討論分層的利弊，可以討論分層有沒有價值……但在這一切一切討論之前，我們要先弄清楚一件事：分層的本質是什么？或者說：分層 是怎么來的？如果這個問題不明晰，那么我們其他的討論猶如“浮沙之上筑高臺”，再精辟的言辭，如果沒有一個牢固的基礎，也是站不住腳的。

    想要了解分層的本質，就不得不說說分工。分工可以說是勞動生產力上最大的改良，最初分工的好處體現在“比較優勢”上，由于各司其職，每個人可以從事其最擅 長的勞動，再加上單純勞動所帶來的勞動熟練度提升和減少了更換勞動時的損失，使得勞動生產率大幅提升。然而，隨著社會的發展，我們發現某些特殊形式的分工 不但可以提高生產力，還有另一些好處！為了理解這些好處，我們舉個實際的例子。

    今天是六一國際兒童節，一位母親想給她的女兒買一個奶油蛋糕作為禮物。我們知道，蛋糕需要面粉、需要雞蛋、需要牛奶等等，還需呀經過一系列復雜的加工和包 裝過程，但是這位母親不需要關心這些，她只要去附近的超市直接買就行了。而超市里既沒有養雞場，也沒有奶牛場，更沒有種小麥(資訊,行情)的農民伯伯和烘 焙蛋糕的工人師傅。這個簡單的“買蛋糕”場景，大約可以用下圖表示:

                            圖1.  制作蛋糕的分工

圖1大約說明了一個蛋糕是如何從到達顧客手里的。可以看到，制作蛋糕不是一個單一的勞動，需要許多的分工，如果自底向上看，主要的分工包括：基礎物質資料的種植生產、原料加工、蛋糕加工、商業銷售。并不是所有分工都如上圖這樣，上圖所示的分工，有一些特點，下面總結一下。

1.下層不知道上層的存在。例如奶牛廠生產牛奶，它不必知道牛奶被拿去做什么，可能被奶油廠收購去做奶油，也可能被雪糕廠收購了做雪糕，也可能被收 購去做奶糖，總之，它只管完成自己的職責——生產牛奶，而對于它的上層一無所知。同樣，奶油加工廠只管生產奶油，它不必知道奶油被拿去做蛋糕還是做摩卡咖 啡。

    2.每一層僅僅知道它的下一層（最后一層除外，因為最后一層沒有下一層），而不知道另外的下層。例如，蛋糕廠只需知道從面粉廠、奶油廠和雞蛋廠提取面粉、奶油、雞蛋就行了，而不必關心面粉是怎么來了、奶油是怎么來的這些問題。

    可以說，符合以上兩點的分工就是分層架構的思想來源。下面說的稍微正式一點。所謂分層思想，就是這樣一種分工：它將系統按不同的職責組織成有序的層次。其 中，除最上層外，每一層僅提供若干服務供其相鄰的上層使用，但不知道上層的存在；除最下層外，每一層僅調用其臨近下層的服務。

    所以，所謂“分層思想”，不過是一種特殊的分工形式。而計算機軟件架構中的分層思想，是將這一思想應用于軟件開發中的特例，而PetShop所使用的 “DAL+BLL+PL”的方式，又不過是將這一思想應用于軟件開發中的特例的特例。例如，如果某個系統的業務很簡單，僅僅是增刪改查，那么BLL就沒有 作用，“DAL+PL”的方式就可以很好完成，這也是很好的分層架構。再如，如果某個系統的業務很復雜，需要先規格化，再做運算，再做整理，那么 “DAL+規格化層+計算層+整理層+PL”這種五層架構也是很合理的啊。如果某個系統BLL所暴露的接口太繁雜，那么使用Facade模式在BLL和 PL之間加一個“FacadeServiceLayer”也是很正常的。再者，如果某個系統不需要數據存取功能，例如計算器程序，我們只是想把表示和業務 （計算功能）分開，那么就沒有DAL了，“BLL+PL”就是合理的。所以，用分層的思想進行架構，本質是“將系統按不同職責組織成有序層次……”這一段 話描述的，而不是簡單“將系統分成DAL+BLL+PL”。

    下面，摘錄一段Fowler在《Patterns of EnterpriseApplicationArchitecture》中對分層的定義：

    When thinking of a system in terms of layers, you imaginetheprincipal subsystem in the software arranged in some form oflayercake,where each layer rests on lower layer. In this schemethehigher layer uses various services defined by lower layer,butlowerlayer is unaware of the higher layer. Furthemore, each layerusallyhides its lower layers from the layers above.

    ——Martin Fowler, 《Patterns of EnterpriseApplicationArchitecture》, P17

    大致譯文如下：

    當我們說一個系統是分層架構的時候，你可以把這個軟件想象成一個有很多層的蛋糕的樣子，其中每一層放在它的下一層上。較高層使用諸多較低層定義和提供的服務，但較低層并沒有察覺較高層的存在。另外，每一層都會對其上層隱藏更低的層。

    ——馬丁 福勒, 《企業應用架構模式》, P17

    但是，這里有一點需要聲明：雖然說“DAL+BLL+PL”不等價于分層架構，而僅僅是一種實例。但同時我們要清楚的認識到，這個方式之所以如此流行，以 至于微軟的官方示例都這樣架構，是因為對于許多系統，特別是大中型MIS系統，這種架構方式是應該優先考慮的。在這一節中，筆者絕對沒有對 “DAL+BLL+PL”進行批判的意思，相反，當開發系統時，這種方式可以優先考慮，然后可以根據系統的特點，進行一定得改良。筆者在本節所強調的是： 不能把“DAL+BLL+PL”看做分層架構的本質，更不能和“分層架構”這個思想概念劃等號。

    分層架構的利弊分析

    在理解了分層架構的本質的基礎上，我們才可以放心大膽的對分層架構進行利弊分析。廢話少講，這一節我們直接切入正題。

    分層架構的優點如下：

    1.分離開發人員的關注。

    由于某一層僅僅調用其相鄰下一層所提供的服務，所以，只要本層的API和相鄰下一層的API定義完整，開發人員在開發某一層時就可以像關注集中于這一層所 用的思想、模式、技術，這樣，就等同于將分工帶來的生產力提高優勢引入軟件開發。又如買蛋糕的例子，作為超市，只要知道下層API（如何從蛋糕廠獲取蛋 糕）和本層需要實現的API（把蛋糕銷售給客戶），就可以制定自己的業務模式很策略計劃了，而不必關心如何種小麥、如何磨面粉、如何做奶油、如何做蛋糕 等。這樣，超市只需進行商業運作，而不必進行產業運作，如此專一，必然提高業務水平。

    2.無損替換。

    想象一下，如果某家奶牛場倒閉了，奶油加工廠也要跟著倒閉嗎？當然不會，它可以迅速更換一家奶牛場，因為各個奶牛場都可以實現“提供牛奶”這項服務。再譬 如，如果某天國家出臺政策，要求所有奶油廠必須從審查合格的奶牛場引進原料，恰好某奶油廠的合作牛奶供應商沒能通過審查，那么，只要換一家通過審查的合作 就行了。而且奶油廠內部的各個環節一動不用動，因為不同的奶牛場都可以提供“供應牛奶”這個服務。而如果奶油廠自己養牛生產牛奶，一旦遇到這個政策，還得 自己去有關部門進行審查，調整相應業務流程，牽一發而動全身。程序中同樣的道理，最常聽說的可能就是遷移數據庫了。

    3.降低了系統間的依賴。

    還是蛋糕那個例子，如果某天蛋糕廠內部換機器了，或業務流程調整了，請問顧客需要關心嗎？顯然不用，因為顧客只調用超市提供的服務。而超市為顧客隱藏了下 面所有產業細節。如果每一個顧客買一樣商品，都要了解這個商品從原料生產到成型再到銷售的一系列細節，豈不累死了。換做程序中，就如表示層只管調用業務層 的服務，至于業務層下還有幾層？各種數據是怎么來的？怎么存的？是真實的還是捏造的？都不需要了解，這大大降低了系統各職責之間的依賴。

    4.復用。

    例如，你可以去這個超市買東西，我也可以去這個超市買東西。蛋糕廠可以從面粉廠提取面粉，饅頭廠也可以。這樣，同樣的層就可以為不同的上層提供服務，達到 了復用的目的。具體到程序中，例如氣象局制作發布了一個“ServiceLayer”，用于提供天氣預告信息。這樣新浪、搜狐這些網站可以利用這個服務層 提供的服務，制作天氣預告頁面，QQ也可以利用這個服務在它的聊天工具上添加天氣預告，你自己做一個軟件需要用到天氣預告功能，也可以調用氣象臺的 “ServiceLayer”。

    說罷優點，再來談談分層架構的弊端：

    1.級聯修改問題。這個問題在現實中不好比喻，但在程序中相信很多朋友都明白。例如，一個人事管理系統，本來查看人員信息只能分頁查看，而現在，需要增加 一個功能：在分頁的同時還能分部門。例如，可以查看“銷售部的前50個人”，這樣，為了這個功能所有層都需要修改。

    2.性能問題。本來直來直去的操作，現在要層層傳遞，勢必造成性能的下降。就如在購買蛋糕的例子中。顧客在享受分工帶來的便利時，也要承受由于不同層的部門分布各地而造成的蛋糕價格上升，這是因為分層增加了成本，如運輸、不同層間部門的協調管理成本等。

    縱觀以上分析，分層架構有利有弊。這是一定得，世上任何事物都有利弊，所以，把“分層架構捧上天”和“一棍子打死”這兩種做法都是不明智也是不科學的。對待分層架構，我們的態度應當是明晰其本質和利弊，然后根絕具體情況做出理性的分析和抉擇。

    從上面的分析可以看出，分層架構可以降低層內變化的成本，而對于API的變化非常敏感。如在級聯修改中提到的“在分頁的同時還能分部門”的新需求，就是對 API進行的變動。API的變動對于分層架構是致命的，修改起來難度非常大。所以，一個簡單的判斷法則就是：如果您的系統層內頻繁變動（甚至整層替換）可 能性很大，而API變動可能性很小，就使用分層；而如果API可能會頻繁變動，那就要謹慎使用分層架構了。