MVC | Kenmingの鮮思維

實作 Enterprise MVC 巨觀結構的 POC－觀念篇

2018-06-12 15:26 | 閱覽人次：6,298 | 尚無迴響

關於 POC (Proof of Concepts)的說明，可參考：「淺論架構的 POC (Proof of Concepts)」。

關於系統結構設計 (system structure design)，個人把它分為兩個構面來看：巨觀與微觀 (Macro/Micro View)。

巨觀結構設計是基於現實系統的分散議題－展示層 (如 Web UI)、永續儲存機制 (如關聯資料庫)，所提出核心業務邏輯應不相依於特定實體元件與實作連結技術的解決方案。這裡推出最實用具應變與可重構的實體分層框架－Enterprise MVC (Model-View-Control)模式 (並非是廠商針對 Web 端提出的 Web MVC 技術)，讓系統主結構 (業務邏輯/資料存取)有效隔離展示層與永續儲存機制的直接耦合 (coupling)。

微觀結構設計則是傳統物件導向所談及從領域概念模型 (domain conceptual model)，導出到軟體物件與資料模型 (class/data model)。這裡使用的分析設計技能包括了運用 Peter Coad 的「交易模式 (Transaction Pattern)」與 GoF 四人幫的「設計模式 (Design Patterns)」。有別於古典OO 一開始就要求較完整的設計 (太過理想化)，現今系統開發則更為務實－運用重構 (re-factoring)的技巧，持續逐漸地重整系統，效果即是簡潔易維護的程式碼 (clean code)。而伴隨著重構的一項必要機制與紀律就必然要求一開始就要撰寫單元測試程式碼 (unit test code)。

上述兩個構面是互補的。軟體主結構一開始就不會實作於特定的UI/資料庫端，以最純淨的 POCO/POJO (plain-old CLR/Java Object)物件來實作，如此才有機會得以實施後續的重構，而重構則取決於某一功能的複雜度與價值來評估，進而創造出系統整體的再利用價值。

本文著重於巨觀結構分層界定與實踐，藉以驗證巨觀結構 POC 的可行性。觀念說明利用 UML 設計圖表現巨觀分層結構；實作則各以 C#.NET 與 Java/Spring 實現一個極小的案例來貫穿整個系統的分層結構元素。

C#.NET 採以 ASP.NET Web MVC 與 E-F (Entity Framework)實作；Java/Spring 則採以 Spring Web MVC 與傳統 JDBC (也可改 Hibernate Framework)實作。兩者會再佐以 UML 循序圖 (sequence diagram)，來輔助解讀案例執行時物件之間的互動合作關係。

巨觀分層結構基本責任界定

把主要分層結構當成元件 (component)看待，以界定各元件主要的責任 (responsibility)。

閱讀全文 »

[軟體課程] 設計模式(Design Patterns)實務與應用－使用 C# 與 UML (11/8,３0 Hrs)

2014-08-05 21:46 | 閱覽人次：4,746 | 1 則迴響

　o 日期：2014/11/08 起，每週六白天。
　　每次上課為六個小時(AM 9:30~PM 4:30)，共八個星期。
　o 預定上課日期：11/08, 11/15, 11/22, 11/29, 12/06
　o 上課地點：上課前一週以電郵/電話通知學員。

§ 課程介紹：

微軟提出 Web 的 MVC 解決方案，並利用 EF (Entity Framework)將 View 的 Model 與資料庫緊密結合在一起。這讓系統開發會更形容易，但反之也造成 10數年前 4GL 盛行時代的 Client/Server 架構－無法有效設計具彈性的結構，來解決多變複雜邏輯的議題。

回歸到軟體人員應具有的基礎功－軟性的設計能力。而這能力的培養，並非由現實對 Web, 資料庫等存取實務技術就可以理解；而是需要研讀大量設計性書籍並具獨立思考的能力，方能設計出某個解決方案 (solution)的結構並應用於實務系統的運作上。

的確，從無到有或沒有方向的摸索是相當不容易的，所以我們會期望能借重軟體先輩們的智慧結晶與設計法則 (Design Patterns)，解決現實設計所面臨的困境與難題；甚而更進一步，能進而活用與創造出所屬自己與團隊的 "設計模式"！

四人幫 (GoF, Gang of Four) 著作的「設計模式 (Design Patterns)」，可以說是軟體領域的孫子兵法。書中介紹的 23 個設計模式，已被大量運用在系統框架(Framework)及應用領域上；不過該書其實艱奧難懂，如同金庸小說中的「九陰真經」上卷一般，充斥的儘是心法，若沒有真經下卷功法的實務修練，是極難打通任督二脈的。

HSDc. 顧問團隊累積了10數年在軟體設計領域上持續研究學習 (大量研讀名家著作/論文)以及實務的經驗 (大型系統開發、顧問/授課輔導、產品開發...)，期能以所累積的心得與實務，並配合現實的實務技術 (以 .NET 為例，會搭配 ASP.NET MVC 與 EF Framework 框架)，把每一個設計樣式，寫成淺顯易懂的案例，讓有志於從事軟體設計業的學員們，可以理解設計模式所揭露的目的與意義，更能應用在現實的工作專案上。

===============================================================================
§ 課程特色：
　o 採 "問題-解決方案(Problem-Solution)" 的說明並佐以生活化的案例，進而帶出程式碼的實作與執行。
　o 以 UML 類別 (Class)圖說明各設計模式內的類別結構關係
　o 透過 HSDc 所開發的 Sequence Generator 工具，產出 UML 循序圖，以展現程式碼動態執行期間的物件呼叫關係。
　o 所有案例均採 ASP.NET MVC 5 框架最新規格，透過 Web UI 來呈現執行的結果。
　o 以四人幫「物件導向設計模式」典藏版一書 (葉秉哲譯)為授課藍本；並再另以講師所提供的案例說明暨程式碼作成簡報講義教材。

閱讀全文 »

ASP.NET MVC 框架學習心得註記

2014-08-01 15:52 | 閱覽人次：4,375 | 尚無迴響

這幾天利用撰寫一個 Web.NET 小專案的機會，打算使用 ASP.NET MVC 5，藉此順便學習下 Web MVC 的框架技術。

花了快兩天的時間研讀一些文章，總算對 ASP.NET MVC 框架有了全貌的認識；先註記下基本的心得：

ASP.NET 源自於 Java Struts MVC，本質完全沒變。
ASP.NET MVC 僅是位於系統 3層(3-tier)架構的 Presentation 層，完全沒有涵蓋系統的控制 (Control)與邏輯 (Logic, or Model)層。
{P.S. 關於這個觀念，個人已在課堂上論述許久；後續再撰寫該篇專文討論。}
ASP.NET 的 MVC 中的 Model，係指 Data Model，也就是屬於資料傳遞類型的物件 (DTO, Data Transfer Object)，並未涉及到邏輯運算。
微軟的企圖心，利用 EF (Entity Framework) O-R (Object-Relation) Mapping 技術，實現 Model (Data Model)與資料庫的無縫式對應，讓開發人員對於撈取資料庫的程序更是簡化不少。
ASP.NET Model 透過 EF 直接對應資料庫，本質上就是 Client/Server 架構；好像重回到 10 年來前 Windows Form 的 4GL，雖然實作變得更簡單 (不需自行控制 Web 表單的狀態與資料庫連結問題)，但會導致系統本質上的混亂－沒有確實隔離問題領域 (problem domain) 的功能控制 (functional control)與業務邏輯 (business logic)層。
ASP.NET MVC 的頁面 (Page)係以所謂的 Razor 語法 (把它想成 PHP 就好了)，以 "@" 為語法的頭尾標記，來實現 UI 邏輯控制的部位。
至於 Web Page 的呈現，則係利用最為普遍的開源專案－Bootstrap，綜合了 HTML/CSS/Javascript 框架技術，來呈現 Web Page 的動態呈現與彈性 Layout 控制 (有些意外，微軟竟然也採用了開源專案)。

淺論 Excel VBA 的 MVC 框架

2013-03-08 07:23 | 閱覽人次：20,446 | 2 則迴響

撰寫即時性的看盤資料分析，最簡單與方便的莫過於利用 Excel 了。工作表 (Worksheet)內的儲存格 (Cell)既可以當成如 DDE or RTD 的資料源，又能做計算邏輯與資料的呈現。而若牽涉到較複雜，如多個儲存格甚或多個工作表、多個工作簿 (Workbook)之間的資料處理，則可利用 Excel 內建的 VBE (Visual Basic Editor)程式開發編輯器來撰寫一般開發人員所認知的「巨集 (Macro)」程式。

VBE 編輯器會為每一個 Excel 檔案配置一個 VBA 專案 (VBAProject)，每一個 VBAProject 可以有四種不同類型的資料夾 (Folder)－「Excel 物件」、「模組 (Module)」、「表單 (Form)」、「物件類別模組 (Class Module)」。其中「Excel 物件」資料夾是預設其內並預設了四個「This Workbook」、「工作表1」、「工作表2」、「工作表3」物件。
Excel VBA Project 組成

這裡帶出一個問題：VBA 程式碼該寫在這四種類型的哪一個資料夾 (或應該稱為哪一種類型的模組)？

或直接把其中最常見的問題更白話：不同工作表之間的資料篩選、處理與搬移等，VBA 程式碼的控制 (Control)與運算邏輯部分，該寫在「Excel 物件」還是「模組 (Module)」？

為了一次性解決 Excel VBA 程式碼結構議題，個人花了兩天的時間思考，先從這四種類型的物件 (可以把這四種資料夾想成四大物件類型)運用物件導向分析思維 (object-oriented analysis thinking)的「責任分派樣式 (responsibility assign pattern)」，先釐清這四大類物件的主要責任。

我這裡先利用 UML 類別圖 (class diagram)，來表達出「VBAProject」與這四種類型的物件結構關係。
Excel VBA Project 的結構關係

閱讀全文 »

由 MVC 看軟體設計思維(2)

2004-11-07 21:54 | 閱覽人次：7,297 | 尚無迴響

觀察 MVC 的設計思維，可以得知：畫面的設計並不是軟體設計的重心首在，畫面是手段，僅是為了表達展示給操作使用者來觀看的，若有更好的畫面呈現方式，系統可以整個抽離掉畫面而不致影響核心，就好比樹葉會代謝再長出新葉也是為了讓整棵樹能呈現更茂盛的一面。

同樣地，資料庫也是手段，是資料儲存的倉庫。若因為分散及負荷的因素，則需考慮配置多個資料庫，甚至，有效能更好、更便宜的資料庫，則隨時可更換之。

畫面(View)與資料庫都是手段，目的即是為了要能維護軟體的主幹–來自專業領域(Problem Domain)上的概念(Domain Concepts)，概念往往成為軟體設計內的企業元件(Business Component)。

為了要能維護企業元件不因外在環境的變動而牽動，進而提升系統的彈性度及增進再利用的價值，軟體開發人員，要能考慮：

變與不變的相對性。
虛與實的相依性。

同時，又要能兼顧系統的效率與問題與使用者的便利性，也要能瞭解：

Stateless 與 Stateful 物件相互的配合。

閱讀全文 »

MVC的軟體設計觀(1)

2004-11-07 20:55 | 閱覽人次：9,857 | 尚無迴響

■ What is MVC?

MVC,Model-View-Controller Separation 樣式(Pattern)
Problem: 希望能夠從視窗畫面(View)之中去掉領域(Model)的耦合，因而支援領域物件(Domain Object)的可重再利用性(Reuse)，而且將對隨領域物件而改變的介面所造成衝擊減至最低，該如何作？ Solution: 將領域(Model)類別定義成無法直接耦合或看見視窗畫面(View)類別，並且應用的資料與功能是在領域物件之內維護，而不是視窗類別。

MVC,Model-View-Controller Separation 樣式(Pattern)

Problem:: 希望能夠從視窗畫面(View)之中去掉領域(Model)的耦合，因而支援領域物件(Domain Object)的可重再利用性(Reuse)，而且將對隨領域物件而改變的介面所造成衝擊減至最低，該如何作？
Solution:: 將領域(Model)類別定義成無法直接耦合或看見視窗畫面(View)類別，並且應用的資料與功能是在領域物件之內維護，而不是視窗類別。

MVC Pattern 其實就是在 Model-View-Controller 三者之間作一個責任的釐清：

View：專注於畫面設計，不牽涉資料與邏輯處理。
Model：反應企業領域中真實世界的概念，例如“員工”、”部門”等物件。在 ”員工”物件中，它專注的責任在於取得(Get)及設定(Set)員工相關的資訊，並負責所需處理的企業邏輯(Business Logic)，如計算員工紅利等 ; 而“部門”物件，則可以取得及設定部門相關的資訊。
Controller：承接 View 與 Model 的中間角色，以維護 View 與 Model 兩者之間的獨立性，並負責控制及協調 Model 內物件的互動邏輯。它的角色就好像是公司的總機小姐，當外部的使用者打電話(View)尋求該公司的幫助時，總機小姐(Controller)會依需求的不同再轉達需求至可以服務的部門工作者(Model)。

而且 View、Controller、Model 有著分層的關係，View 可以看見或者傳送訊息到 Controller或 Model 物件，反之，Controller和 Model 物件將會忽略視窗畫面的存在。
未了解 MVC 樣式，而把這些物件都混在一起，使用者介面程式往往亂成一團。
MVC 解開糾結，增進彈性及再利用性！

閱讀全文 »