第三章 系統分析與設計
3.5 線上學生課務資訊系統模型
public:
static Singleton GetInstance() {
if ( instance == null )
instance = new Singleton();
return instance;
} private:
Singleton();
Static Singleton instance;
}
這種設計比單單只是定義成全域或是靜態變數更為優良有彈性，
並且確保了類別實體的唯一。像這種可輕易設計出良好解決特定問題 的架構，便是 design patterns 的威力。
3.5 線上學生課務資訊系統模型
最概括的說，系統可描述成以下的模型。
圖 3-10 概括的線上學生課務資訊系統模型
使用者使用線上學生課務資訊系統（以下簡稱課務資訊系統）查 詢資料，課務資訊系統向資料庫抓取資料並對其做必要的運算後，將 結果回應給使用者。
現在考慮課務資訊系統中的架構，因採用 ASP.NET 來實作課務資 訊系統，故需依照 ASP.NET 所訂定的架構來建立系統。在 ASP.NET 的架構裡，網頁上的表單控制項皆被包裝成 Web Control 元件，並使用 了事件驅動和資料繫結的開發方式，使得讓前端的 UI 介面和後端的程 式碼可清楚地分開撰寫，即是 Design Patterns 中的 Mediator1模式和 Observer2模式的混合運用。ASP.NET 又透過 Code-Behind 的技術，將 程式碼和展示用的 HTML 標籤分開在不同的檔案，使程式更可讀性，
其中 HTML 標籤是寫在*.aspx 的檔案中，而程式的部份則寫在*.cs 中。
故對所有的子系統，我們可一般化成下列模型。
圖 3-11 ASP.NET 的系統模型 此即為傳統的三層式架構。
1.Gamma,Johnson,Helm,Vlissides 著，葉秉哲 譯，物件導向設計模式，培生，台北，
2001，p313
??????
首先我們先考慮使用者的問題，因使用者的不同，所需對應的邏 輯層便不同，例如以社團帳號登錄的使用者，其首頁便不應該出現個 人課表的功能，故系統應能依使用者的類別不同，顯示出符合其身份 的功能。
第一種做法是更改展示層，顯示為不同的使用者建立相對應頁 面，在使用者登入時便導向所應該顯示的頁面，此種做法會使得每一 頁的重覆性過高，並且維護不易，若再新增一種使用者，一樣要花費 同樣的工夫建構。
第二種做法是依使用者不同，更改其對應的邏輯，使用程式去更 改頁面成符合使用者身份的顯示。為了不使得對應的邏輯寫死於程式 中，造成日後維護的困難，故我們使用了 Strategy1模式，將依使用者 不同所對應的邏輯給封裝起來。
? ? ? ? ?
? ? ? ? ?
? ? ?
? ? ? ? ?
? ???????? ?
圖 3-13 線上學生課務資訊系統系統模型之一
整個架構便成了 Smalltalk 裡的 MVC 設計。View 負責顯示畫面，
為 HTML 標籤，（即*.aspx 檔），而 System.Web.UI.Page 退化成了 MVC 設計中的 Controller，只負責對使用者介面的輸入做出相對應的處理和 將結果回應於 VIEW。其餘的部分則為 Model，負責應用軟體物件。我 們訂定出了 Page 的責任，接下便可繼續思考 Model 中的系統的架構設 計。
抽象類別 Group 定義出在此系統中所需那些運算，再分別依學生 或老師的不同分別實現其實際的動作。Config 類別用來存取 Config.xml 檔，此檔案記錄著系統管理者所做的設定。
此設計的好處在於讓 Controller 可以對所有的使用者皆一視同仁，
做出相同的動作。而使用者之間的所需差別，則由使用者所屬的群組 自行負責，日後若要新增新種類的使用者，只需增加相對應的群組做 出其所需的邏輯即可。
但目前的設計卻會使得資料庫與系統過分耦合，一但資料庫系統 更換，便得重新撰寫 Student 和 Teacher 中對資料庫動作的所有程式碼。
另外在.NET Framework 中，對資料庫的操作模型為 ADO.NET。
它提供了 Data Provider 物件用來連接資料庫、執行資料操作指令、取 回查詢資料等功能。但對於所連接的資料庫不同，其所對應的 Data Provide 物件也不同。若連接的對象為 SQL Server，便應使用 SQL Server.NET Data Provider，若連接 Oracle 資料庫，便應使用.NET Data Provider for Oracle。也因此，對於使用的資料庫的不同，便要重新撰寫 所有有關資料庫連接部分的程式碼。
所以讓我們先考慮課務資訊系統資料庫，依學校的不同，所使用 的資料庫便可能不同。若將資料庫的操作方式寫死在程式中，將來移 植時必然要花費很多心力，並且每一 Group 子類別皆各自連結資料庫，
出錯的機會亦會大大上升，也造成維護上的困擾。
所以我們使用 Facade1模式把所有對資料庫的動作單純化為
Select、Insert、Delete 和 Update 四個動作，以及使用 Bridge2模式將操 作資料庫和如何連結資料庫的實作部份分開。 式，將其所對應的 Data Provider 轉換成符合 ConnectDB 的介面即可。
但是在 Group 中仍然需要指明所需的 ConnectDB 子類別為何，並 無法在程式執行時動態地去挑選要連結的資料庫引擎。我們希望系統 能和使套裝軟體一般的方便，可依系統管理者的設定，自動創造合適 的 ConnectDB 子類別，如此在移植時便能做到最小的改變。所以加上 了退化的 Abstract Factory4模式，讓系統自行判斷，動態生成合適的 ConnectDB 子類別。
1.Gamma,Johnson,Helm,Vlissides 著，葉秉哲 譯，物件導向設計模式，培生，台北，
2001，p211
1.Gamma,Johnson,Helm,Vlissides 著，葉秉哲 譯，物件導向設計模式，培生，台北，
2001，p173
1.Gamma,Johnson,Helm,Vlissides 著，葉秉哲 譯，物件導向設計模式，培生，台北，
2001，p159
因此，系統便成了下列的模型
圖 3-15 線上學生系統模型之三
CreatConnectDB 會依 Config.xml 的內容，選擇要生成何種的 ConnectDB 子類別。
接下來，我們再繼續考慮關於課程資料庫的變化。為了操作的方 便性和一致性，我們亦利用 Adapter 模式將對課程資料庫的操作包裝成 ConnectDB 的介面。
圖 3-16 線上學生課務資訊系統模型之四
考慮課程資料庫的變動，和課務資訊系統資料庫一樣，隨著學校 的不同，課程資料庫可能為不同種類的資料庫系統，而且絕大多數的 Table 定義都可能不同，Table 名稱不同，欄位名稱不同，Table 之間的 關係也不同，甚至可能分散到好幾個資料庫裡。所以想要轉移系統至 其他學校，修改程式碼是無可必免的。
我們必須思考一種好的做法使修改的程式碼維持最小，讓系統的 主要邏輯不受到資料庫變更的影響。是故，利用資料庫中 VIEW 的觀 念並運用『找出變化，並封裝它』的準則，我們定義出了一個虛擬的 資料庫，讓系統對於課程資料庫的操作皆使用這個虛擬資料庫的定 義，再由虛擬資料庫轉換為真正課程資料庫的定義，使得課程資料庫 整個? 藏起來，系統只對表面上的虛擬資料庫做動作而已。如此，當 課程資料庫變更時，便單單只需改變虛擬資料庫這部份的實作即可。
圖 3-17 線上學生課務資訊系統模型之五
接著，為了讓課程資料庫的改變對系統的影響減至最小。我們將 虛擬資料庫移出系統，並包裝成 COM+元件，讓它真正與系統獨立運 作，並可依課程資料庫的改變，輕易抽換，而不用重新改寫系統。
圖 3-18 線上學生課務資訊系統模型之六 因此系統的整體模型如下
圖 3-19 線上學生課務資訊系統模型之七
最後考慮 Config 物件，因為系統是架構在 Web 之上，因此我們在 存取 Config.xml 檔時，必須要先把 Web 伺服器上的虛擬路徑轉換成為 實體的檔案路徑，才可存取的檔案，是故在 Config 中，本身應有能力 把 Config.xml 的虛擬路徑轉為實體檔案路徑以供後續動作使用。但在 ASP.NET 中，提供此轉換功能的物件只能由 ASP.NET 應用程式實體 化，所以 Config 勢必得提供一方法，接受此一物件，才能在內部進行 路徑的轉換。
問題在於此一物件是 System.Web.UI.Page 中的屬性，若要讓 Group 包含 Config，就必須讓物件先由 Page 傳向 Group，再由 Group 傳至 Config，讓 Config 進行轉換，這麼做的話便會使得系統的耦合性提高。
若讓 Config 在 Page 初始完成後再交由 Group 使用，又會讓 Page 的責 任變的模糊不清，讓系統的設計不合理。
因此，為了解決此一問題，我們配合了 ASP.NET 的設計，在
ASP.NET 應用程式開始執行時先行初始化 Config，為了避免（也無法）
使用全域變數，故利用 Singleton1模式讓 Config 可保持此實體，使得雖 然不用宣告 Config 型態的全域變數，也能讓 Group 物件能夠使用 Config。
1.Gamma,Johnson,Helm,Vlissides 著，葉秉哲 譯，物件導向設計模式，培生，台北，
圖 3-20 線上學生課務資訊系統模型
至此，整個系統的主要模型便建立完成了。在各子系統中，其主 要架構便是如此，但會考慮其差異性和特殊之處，依情況做個別的調 整。
表 3-2 線上學生課務資訊系統各類別所負的責任
名稱 責任
HTML 負責在使用者瀏覽器中，顯示使用者介面。
Page 負責對使用者介面的輸入做出相對應的處理和將結果反 應至顯示上。
Group 定義系統所需的運算介面。
Student 實作符合 Group 定義的運算，供使用者為學生時使用。
Teacher 實作符合 Group 定義的運算，供使用者為老師時使用。
ConnectDB 定義操作資料庫的介面。
ConnectSqlDB 實作 ConnectDB 介面，負責連結 SQL Server 資料庫。
ConnectSchoolDB 實作 ConnectDB 介面，負責連結虛擬課程資料庫。
CreatConnectDB 負責依管理者設定，選擇連接何種課務資訊系統資料庫。
Config 存取設定檔，並定義操作使外界存取自己唯一的實體。
SchoolDB 建立虛擬的資料庫，負責與實際課程資料庫之間的轉換。