機房重構包圖（從三層+實體到三層+實體+外觀+工廠+接口+SQLHelper）

剛剛開始接觸三層的時候，我隻做了兩個登入小窗體的例子。畫了簡單的包圖，可以說，為後面機房重構留下了大量的工作（因為三層了解沒有深度，也沒有了解出自己的東西）。不過，欠下的總要還的。在做機房重構的時候，問題出現了。如果隻用三層+實體，我能做出來，但是，要求重構不能隻用三層+實體，那麼，就要好好分析一下了。

首先說說三層+實體：就是表現層（U層）直接調用業務邏輯層（B層）的邏輯，業務邏輯層在直接通路資料層（D層），在把資料傳回到B層後傳回到U層。首先，隻用三層＋實體做程式時，靈活性不夠高。如果想換資料庫的話，需要大量改動B層的代碼。其次，代碼使用率不高，像通路資料庫的一些代碼，多次重複。

既然不好，就有必要尋找新的方法。B層直接通路D層不好，怎麼辦呢？用接口。這樣，如果更換資料庫，隻要把D層進行修改或者在連接配接新的D層，而不用更改B層的代碼了，實作“高内聚，低耦合”。U層直接通路B層，U層需要知道B層的就太多了，耦合性太高。我們的系統簡單，一個上機窗體裡面就兩個主要功能，但是一個窗體上面内容多的話，那U層和B層的對應關系不是很亂了麼？這時外觀就出動了。如果U層通過外觀通路B層的話，可以避免這一問題。

那麼，又為什麼要使用SQLHelper呢？其實，SQLHelper是一個工具，主要是為了規範代碼和減少代碼編寫，如果想了解更多，可以參看另一篇部落格：SQLHelper

下面是我畫的由三層+實體到三層+實體+外觀+接口+工廠+SQLHelper的包圖，歡迎指正

小結：首先，無論在學什麼知識的時候，即使很簡單，也要小結幾句，否則下次想用時，無從下手，三層就是個活例子。其次，多請教，多交流，對于不會的東西，勤于動手，等待是解決不了問題的。再次，對于三層這塊，隻要通了，感覺就好多了，剛剛開始做包圖的時候，真的是無從下手，即使給你現成的圖，也會有看不懂以及為什麼會是這個樣子的疑問（我相信不止我自己有這種感覺）。我建議，如果出現這種情況，先放一放圖，試着通過代碼，了解一下這個過程，雖然可能有點難度，但是總比停下來或者揪住一點不放要好的多。

PS：歡迎指正，不勝感激！