三層架構之實體層以及外觀

         昨天，七期師兄師姐們給我們講解了一下三層和三範式。

         關於三層：

         對於三層的理解，一直在一步步的加深之中，不論理解的對與錯，至少現在和別人說三層，能說出一點點的皮毛，但是再往深一點說，就不會了。

         聽了昨天的講解，發現最難理解的其實並不是B層，也不是D層，更不是U層，而是實體層。

         BLL層主管商務邏輯，也就是說和業務有關的放在B層。U層是表現層，主管和使用者的互動，使用者輸入，以及向使用者展示都是U層的事。D層為資料訪問層，主管和資料庫打交道。

         前些日子看了篇關於三層的文章，在他的文章裡說驗證是否為空白等一系列放在B層。關於這個，仁者見仁，智者見智。有人認為只要涉及到判斷，那麼就應該放在B層，也有人認為，這個是與介面相關的，所以放在U層。

         放在B層的好處是什麼呢？那就是U層的代碼可以再少一點，在更換介面層的時候，新的U層只需要傳值即可，這樣的話B層就會變的特別臃腫。我感覺著也就是大家都說B層是最麻煩的原因了。

         我個人感覺最難理解的是實體層，這一層是“跳出三界外，不在五行中”。它不屬於三層中的任何一層，但是三層每一層都與他關聯。最初的理解是有多少個表，就最少有多少個實體類，每個實體類的屬性為表的欄位。

       慢慢的，覺得這樣劃分實體類是有問題的，因為涉及到多個表的時候，那麼就返回不了實體類了，因而出現了基於視圖建立實體類。宏哥的一句話更是點醒夢中人：其實你都可以將九個表的欄位全部寫到一個實體類裡面。

       雖然大家都不會這樣做，但是這個思想告訴我們，實體類並不是規定死的，他可以完全按照你的需要進行改造，怎麼用更符合物件導向，就怎麼用，沒有那麼多的條條框框。這也就是他“跳出三界外，不在五行中”的原因吧。

       而面對返回datatable，u或b層需要知道欄位的問題，則是在實體層寫一個參數為datatable類型的方法，那麼瞭解欄位的責任就交給了實體層，這樣，就做到了u、b層與D層的解耦。

       我們畫圖的時候，有的人加了外觀，昨天師姐問我們是否想過這些細粒度的包怎樣對應粗粒度的包，這個其實並不太難，所以就不說了。下面附圖再解釋下個人對外觀的理解吧（上篇中已經文字敘述了對外觀的理解——機房收費系統總結之圖情結）：

       這次的舉例為上下機執行個體，首先我們看一下外觀帶邏輯的圖：

在這個圖裡，B層是基於U層寫的，但是在B層差不多之進行了return類似的語句，相應的判斷幾乎沒有，這些工作都交給了外觀層來解決。外觀是用來解耦的，這樣其實並沒有達到解耦的目的，昨天開會的時候，勇哥說解耦最好的方法就是介面，而這裡外觀提供的並不是一個介面，而是類似於B層的一個類。用了外觀，就好像把B層架空了一樣，跟外觀層直接調用資料訪問層的感覺差不多。

下面在看下外觀沒有邏輯的圖：

（中在B層省去了其他的關聯關係）由於檢測卡號是否存在以及檢查是否正在上機要重複使用，那麼在B層將其抽象出來以達到複用的目的。在這裡，相應的邏輯都存在於B層之中，B層做了自己應該做的，並沒有交給外觀，所以個人感覺雖然說可以將細粒度的包和粗粒度的包對應，但是是有區別的。

下面再說下外觀存在的意義，如果沒有外觀，那麼將會是下面的圖：

      

這樣，U層需要知道B層的就太多了，耦合性太高。我們的系統簡單，一個上機表單裡面就兩個主要功能，但是一個表單上面內容多的話，那U層和B層的對應關係不是很亂了嗎？這時外觀就出動了。

在套用面板時，我們不能將B層應該做的放到外觀做，就好比你D層的代碼寫到傳參等一切都繼續了，就差cmd的execute，然後你返回一個cmd，讓他在B層execute吧（可能不恰當，但是道理是相同的）。

對於設計模式的理解，任重而道遠，在自己的機房收費系統裡面所用的設計模式，除了抽象工廠加反射利於更換資料庫外，其他的功能感覺都有點牽強。

本來要寫成兩篇的文章，寫到了一起，大家一定讀累了，再次感謝您的拜讀。

下回說一下機房收費系統所用的設計模式。