淺論 Visual Studio .NET 專案開發的目錄規劃議題

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

「由於老師上課時都是以 “類別 (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 圖來表達方案與專案的複合結構關係,可以參考如下圖:

.NET Solution 與 Project 的複合結構圖

那麼到底一個系統的開發,分為幾個專案比較恰當呢? 這當然還是要看專案的性質與規模而定。 但我強烈建議,無論如何,最起碼一定是至少兩個專案: 含企業邏輯(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)” 了。

文章導覽

   

共有 2 則迴響

  1. Hello 神來之筆:

    PIM 與 PSM 是抽象的層次不同,但並非是區分 Business or Information System 的結構設計。

    所謂 Business Model 或 Information System Class Model,是端賴系統的設計範圍不同而不同。 那是與 PIM/PSM 根本沒有任何關聯的。

  2. Hi Kenming ,
    依照您建議要分層四層
    那在邱老師書(寫給SA的UML/MDA食物手冊)中,經過PIM後所產生的類別圖
    是歸屬於business model那層?

    神來之筆

發表迴響

你的電子郵件位址並不會被公開。 必要欄位標記為 *