Y11 設計想法彙總(1)──層次與使用定義

這陣子會去思索至今為止我想做出來的設計到底是什麼？能否整理清楚並明確地傳達給別人？是否有足夠的理由與好處去說服周邊的人承受較多的不便去遵循？這些都盤踞在我的心裡。

首先是關於層次的設定，像下圖中這樣Business Module、Module、Component、Utility從上到下佈置下來的方式，雖然安排的層次上或多或少有所不同，但是由上到下的使用關係都是大家所習慣的作法。這裡我想要討論的是：需要開發電子日誌商業模組時決定要使用外面開發的DB存取元件，應該直接從電子日誌模組使用？或是定義一個自有的DB存取元件使用，電子日誌模組只呼叫它呢？（如果只看功能，程式怎麼布置都可以達成）



最快的方式是在電子日誌模組裡直接使用外部的DB存取元件，這意味著模組與外部元件有不可分的相依性，所幸這個問題在遇到第二種資料庫時就會因為想要抽換實作層而自己布置一個Component來負責。再接著會遇到一些通用機制需要設計（像是roll back、SQL command管理等），那些是所有使用DB的商業模組必須應用的，但是若想放在功能性強的Component又會感覺綁手綁腳的。



從上方往下看是這張圖中像洋蔥的結構，Use Case劇本呼叫的是Business Module的方法，再一層層地向內使用，外部元件全部由Component包在其內部使用，在其他任何層次都不會接觸到。在這種結構下，與外部的接觸點只限於Component層（Utility也可能會使用到外部Class），可以避免在任何模組或元件都能使用外部元件。

一致的層次設定與使用規則，是最開始就需要定義好的布置框架。