VDB 理論與設計 — Ringle Lai；本次範例實現 — Steve Chou：編排與修正 — Kenming Wang。

虛擬DB(Virtual DB) 並非特定平台的實做技術，其主要特性如下：

針對某一個特定的任務，將該任務所需的相關資料由各種不同的資料來源取得至 記憶體(Memory)中，讓相關的處理程式可以「就近處理」這些資料；其與資料來源的實體儲存格式無關，且在取得資料後，應該保持與資料來源「離線 (offline)」的方式來進行存取，而 虛擬DB 只提供資料的存取，不負責進行運算。

也因此，Java 世界中的 Value Object 其實也是「虛擬DB」的一種體現；至於在.NET Solution中，最適宜表現虛擬DB的技術就是 ADO .NET 中的「DataSet」技術。而 Business Object 與 Value Object 最大的差別在於 Business Object必須要有「企業運算邏輯(Business Logic)」。舉例而言，下圖就是一個典型的Business Object的類別圖：

（點擊圖片鏈接看原圖）圖、典型的 Business Object 類別圖

根據前述的 Business Object 的定義，我們可以發覺在上圖中，Business Objcet只有兩個，分別是：

• Order Class – 因為其有一個【CalculateTotalAmount】的 Business Method；
• OrderItems Class – 因為其有一個【CalculateSubtotal】的 Business Method。

而在該圖中，Product Class 因為只有一個 Getter 的 Method，因此可以將之視為 Value Object，至於 OrderItems 也有一個【Quantity】的屬性，因此也具備了 Value Object 的性質。

一般來說，Business Object其實通常具備了三個主要特質，分別是：

• 資料面 – 這通常會以【屬性(attributes)】來呈現。
• 企業邏輯 – 這通常是除了 Getter 與 Setter 之外的 Method。
• 結構面 – 也就是類別間的靜態關係(包括 Association、Aggregation、Generalization 以及Dependency 等)。

然而，當我們有了 虛擬DB 的概念後，資料面的部分可以交由 虛擬DB 代勞，因此，Business Object就只存在了企業邏輯以及結構面。

我們可以利用UML的 Composite Structure Diagram(複合結構圖) 來表達 虛擬DB 與 Business Object 兩類元件的關係：

（點擊圖片鏈接看原圖）圖、虛擬DB 與 Business Object 間的關係

在這一期剛結束的「系統分析設計與實作」的課程中，有位女學員問了一個問題：

「由於老師上課時都是以 "類別 (Class)" 為單位，來說明類別之間的連結關係；但是，在微軟實際的發佈(Deploy)，卻是以 "DLL" 為單位，而一個 DLL 檔案，可能會包含了一到多個類別，若是被呼叫的某一個類別有經過編輯修改後，則整個 DLL 檔就必須重新編譯，相當地麻煩。 所以，到底該如何規劃這些類別的配置呢？」

先說明一下這個問題，是屬於 "相依性(Dependency)" 的設計議題。 小至以類別、套件(Package) 為單位，大至以模組 (Module)、子系統(Sub-System)、系統，都有這類相依性的設計考量。

DLL，全名為 "Dynamic-link library (動態連結函式庫)"，中文版的 Wiki 解釋是這樣的：

「所謂動態連結，就是把一些經常會共用的程式碼(靜態連結的OBJ程式庫)製作成DLL檔，當執行檔呼叫到DLL檔內的函數時，windows作業 系統才會把DLL檔載入記憶體內，DLL檔本身的結構就是可執行檔，當程式需求函數才進行連結。透過動態連結方式，記憶體浪費的情形將可大幅降低。」

上述這一段的解釋應該是從系統實作(Implementation)的角度來說明的。 在邏輯性的設計觀念呢？ 應該是稱之為 元件(Component) 最為恰當了； 在 UML 的塑模(Modeling)階段，則是以 套件(Package) 為單位較適合； 至於在微軟的 Visual Studio .NET 中，則確然是以 "專案(Project)" 為單位無庸置疑了。

而 VS.NET，則有兩種專案開發的容器(Container)類型，一就是上述所提的 "專案"：另一個就是所謂的 "方案(Solution)" 了。 一般說來，方案即為 "大" 的容器，一個方案可以包含一到多個專案，而且，最頂層的容器，必然是以方案為單位，也就是說，即使只有一個專案，也仍需要有一個方案存在。 這是相當合理的，較早免費版的 VS.NET Express 版本，只能以獨立的一個專案為開發單位，這反而不妥。 畢竟，專案開發時，必然會有多個相關連性的專案存在，以方案將多個專案 "聚合(composite)" 在一起，是比較恰當。 從 UML 圖來表達方案與專案的複合結構關係，可以參考如下圖：

那麼到底一個系統的開發，分為幾個專案比較恰當呢？ 這當然還是要看專案的性質與規模而定。 但我強烈建議，無論如何，最起碼一定是至少兩個專案： 含企業邏輯(Business Logic)的 Model 專案，以及 UI(User Interface) 專案。

UI 專案相依於 Model 專案，反之則否。 所以當 UI 未來會變動時，例如從 ASP.NET 改為 Windows Form，Model 專案是不需要作任何變動的。 當然，這樣的規劃起碼有個前提： 不會把 企業邏輯 實作在 UI 專案，而這點，應該也是軟體開發最基本的彈性度考量了。

再講究一點，對於大規模如 ERP 系統的開發，更需要考量到未來系統的變動性與延展性等議題，所以對於彈性度與可容易抽換的再利用性，自然要求就更為嚴謹了。 可以參考一下先前我曾寫過的一篇：「淺論資訊系統的分層結構」， 那個圖內的每一個框框所表示的套件(Package)，都會被規劃為一個個的專案。 所以，在 UI 層，會有個 UI 專案；在中間層(Middleware)，則會有如 "Control"、"Business Model"、"Boundary" 三個專案的規劃。 參考如下，在 VS.NET 建立一個 Solution 方案，例如名稱為 "ERP System"，然後再建立起四個專案目錄。

ERP System (Solution)
-- Web_UI
-- Control
-- Business_Model
-- Boundary

"Control" 顧名思義，屬於在 Enterprise 系統中 MVC 基本框架中的 Control，它橋接了 UI 與 Model，也讓其兩者沒有耦合(Coupling)在一起； Model，也就是物件導向中，代表問題領域概念呈現所稱之為的 企業物件，也是軟體的主結構。 只是，國內短線專案很少重視這一塊，往往會與 Control 層糾纏在一起，以及退化成為資料庫內的 Data Model(資料模型)； Boundary，連結資料庫或者外部系統。 連結資料庫這一層稱之為 "DAO 物件(Data Access Object)"、連結外部系統這一層稱之為 "Adapter 物件"，此兩者都會因連結的資料源(Data-Source)變動而必須調整，但不致也不應該影響到 Control or Model 層。

上述例子中的 ERP System 方案，在開發階段中，規劃了四個專案目錄，所以未來經過編譯後，會有四個 DLL 檔案(當然，若以 WebUI，可能有它特別的格式，但是，對於微軟的角度來說，執行期間(run-time)的一組群組(Group)起來的物件或函式庫，都可稱之為 DLL)。 再經過分層結構的相依性分析，就會瞭解到 DLL 之間的相依性關係，以及抽換某個 DLL，是否會影響到另外的 DLL。

除此之外，分為如上四個專案，還有個好處： 在開發階段可以平行分工！

例如，開發 UI 專案的團隊，不用也不需瞭解後端包括 Model 層或連結資料的 Boundary 層，它只需要負責與 Control 層溝通即可； 而 Control 層，會定義系統功能的規格，包括呼叫的名稱(也就是 method 名稱)、參數與回傳值等，只要先規範好這些規格，供 UI 團隊連結呼叫即可，開發初期不需要得等到實際連結到資料庫這段工作；而 Model 這一層，甚至可以延後到系統實際上線(供 End User 操作使用)後，對於所謂企業邏輯共用性的設計需求考量，再施以結構的重整，也就是現在很熱門、從程式碼的角度來稱謂的 "重構(Refactoring)" 了。