JWorld@TW the best professional Java site in Taiwan
      註冊 | 登入 | 全文檢索 | 排行榜  

» JWorld@TW » .Net Framework  

按列印兼容模式列印這個話題 列印話題    把這個話題寄給朋友 寄給朋友    訂閱主題
reply to topicthreaded modego to previous topicgo to next topic
本主題所含的標籤
作者 淺論 Visual Studio .NET 專案開發的目錄規劃議題
kenming





發文: 194
積分: 10
於 2009-01-09 23:56 user profilesend a private message to usersend email to kenmingreply to postreply to postsearch all posts byselect and copy to clipboard. 
ie only, sorry for netscape users:-)add this post to my favorite list
在這一期剛結束的「系統分析設計與實作」的課程中,有位女學員問了一個問題:

「由於老師上課時都是以 "類別 (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)" 了。


reply to postreply to post
=$∼寸心千里∼$=
= blog: http://www.kenming.idv.tw/
= 軟體課程訊息 http://www.hsdc.com.tw/
» JWorld@TW »  .Net Framework

reply to topicthreaded modego to previous topicgo to next topic
  已讀文章
  新的文章
  被刪除的文章
Jump to the top of page

JWorld@TW 本站商標資訊

Powered by Powerful JuteForum® Version Jute 1.5.8