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

這幾天利用撰寫一個 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 控制 (有些意外,微軟竟然也採用了開源專案)。

[好書分享] Clean Code~無瑕的程式碼

無瑕的程式碼:敏捷軟體開發技巧守則 無瑕的程式碼:敏捷軟體開發技巧守則 (中譯本)
Clean Code: A Handbook of Agile Software Craftsmanship
-----------------------------------
作者:Robert C.Martin
譯者:戴于晉、博碩文化
出版社:博碩
ISBN:9789862017050
Amazon 評鑑:四顆半星

內容簡介
本書的原文書名為《Clean Code: A Handbook of Agile Software Craftsmanship》,根據作者的說法,《無瑕的程式碼》為Jolt得獎著作《敏捷軟體開發:原則、樣式及實務》的前傳。

在台灣另一本銷售極佳的書籍《重構─改善既有程式的設計》,根據亞馬遜Amazon網站的統計,購買該書原文版《Refactoring: Improving the Design of Existing Code》,又同時購買的其他書籍第一名,正是《Clean Code: A Handbook of Agile Software Craftsmanship》這一本書。

.第一章
作者開宗明義說明什麼是 Clean Code,他詢問了包含C++發明人 Bjarne Stroustrup、Eclipse 策略教父 Dave Thomas、極限程式設計大師 Ron Jeffries、維基與極限程式設計發明人,Ward Cunningham 等等的大師,從他們的眼光來描述什麼是 Clean Code,最後才說到作者本人認為的 Clean Code 應該長成什麼樣子,有什麼好處,以及學習撰寫Clean Code的基本原則。

最早知道這本書大約是前年 Ringle 已購買的原版書籍,並發現他常在課堂教授的空檔就津津有味地細讀該書,我想會吸引他如此認真閱讀絕對非同小可。不過當時我拿來略翻一下,有太多生活化的白話字彙 (如同極致軟體系列,但卻又更厚上太多),要翻查這些生字太吃力了些,故而放棄閱讀原文。沒想到國內出版社今年有相中該書,將之翻成中譯本,而且許多專業字彙還保留了原文的對應 (我很習慣軟體的原文字彙),讓我得以在兩個星期內就看完本書,而且到第10章以前 (約一半),可是逐字細讀。第10章以後,總感覺有些雜燴,有些是其他作者的論文,有些是原作者早期的文章,有許多主題已經是偏向程式開發領域的技術性議題,用來解釋「Clean Code」,我是覺得反而沒必要細讀,大略知道本意即可。

當時 Ringle 告訴我 Clean Code 的原則就是:每一個函式 (function, or method),不超過10行,最好是5行以內。天啊,這讓我很難以想像,我知道函式不能肥大,也不要有一堆的 if-then-else or switch 之類的判斷式,但如何縮短為只有10行以內的寫作,我也很難理解。不過細讀本書內容之後,總算能瞭解要如何作,當然,你更應該體會為何要這麼作。

簡而言之,程式寫作是一門「craftsmanship」,我還蠻喜歡中譯本將之翻為「工藝典範」。它既要精確,卻也期望將程式寫作昇華為具有美感的作品。我覺得,稍具有良心與審美觀的程式設計師,絕對不是只有滿足於「可以執行程式」。寫出來程式往往只是起點而已,持續不斷地精煉 (也就是重構),讓程式整潔,軟體才有可能具彈性與維護性。往往程式設計師只滿足於讓程式「順利運作」的狀態,有經驗豐富 (還有良心)的程式設計師,知道那其實是一種專業上的自殺行為。

所以,事實上,寫程式就如同寫散文一般,程式寫得艱澀冗長讓人無法理解,就代表散文寫作能力不佳。程式設計大師不認為他們在寫程式,而是在說故事。大師利用所選定的程式語言機制,來幫助建造更豐富更具表達力的語言,讓這個語言可以用來說故事。而簡短的函式,有意義的命名,以及漂亮的結構,則都有助於描述故事。

閱讀全文 »

Excel VBA-關於儲存格變動性的設計議題

問題:當工作表內有多組被參照的儲存格需撰寫 VBA 程式作處理運算,但不希望因被參照儲存格的位置 (座標)變動後,而頻繁修改程式碼。

描述:參考下圖,當有一組表格內的儲存格,例如「加權指數」,有包括「成交價」、「最高價」、「最低價」、「成交量」... 等屬性 (property)。若撰寫 VBA 程式時,係以「絕對座標」參考值 (例如「成交價」座標現為 "B4")來處理,則當上述任一屬性座標更動時 (或新增屬性而移動原來屬性位置),程式碼必須修正調整。這也說明了若以單一儲存格的「絕對座標」作為撰寫程式的參考值,不會是好的寫作方式。
Excel 儲存格

解決方案:利用 Excel Range 物件,標定一組儲存格作為參考表格,再以「相對座標」來取得所參考的儲存格。

閱讀全文 »

淺論 Excel VBA 的 MVC 框架

撰寫即時性的看盤資料分析,最簡單與方便的莫過於利用 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 的結構關係

閱讀全文 »

[案例研討] 雲端與安卓系統分析與實作-以豪小子App為例-06

*** 自本篇後續所有的文章內容,作者為賴信仁 (Ringle Lai),並已經由授權延續本案例研討系列。***

 

七、 雲運算技術總覽

7.1. 雲運算的歷史與分類
自從互聯網(Internet)開始進入電腦的世界以來,電腦技術的進展,以超越人類能夠想像的速度超高速發展中。

中國人有句話說:「積沙成塔,聚少成多」,用這句話來形容近來的電腦運算能力的進展,是再適合也不過的了。

在網路環境還不發達的年代中,所有的電腦都是獨立的個體,各自有各自的運算能力,彼此沒有辦法互相溝通,因此,要進行大量的運算,就必須要架構出「超級電腦」來進行超大量的運算;

當網路環境越來越成熟時,區域網路利用「乙太網」(ethernet)進行溝通,因此,在區域網路的環境中,可以架構出「叢集式運算」(Computer Cluster)的環境,讓多個Server可以透過互享資源的方式,將運算能力以倍計成長;

但「叢集式運算」的環境,對於很多的系統管理人員來說,卻是一個惡夢的開始,系統管理人員必須耗費相當多的心力來架構出「叢集式運算」的環境,而硬體及軟體成本也因為要架構出這樣的環境而大幅飆升,原先只是想要取代大型主機,卻發現要耗費的心力其實比維護大型主機更多!

基於這樣的一個背景,有些人開始思考是否有更簡單的方法來架構出一套具備叢集式運算能力,但在管理上更簡單、成本上更節省的方式。

「網格運算」(Grid Comupting)就是在這樣的背景上應運而生。

由於網際網路的傳輸能力大幅提升,無論在速度或是可靠性上,網際網路的能力都逼近了區域網路,因此,是否能夠運用網際網路的特性來進行分散式的運算,就成了計算機科學中的「顯學」。

網格運算主要是將整體的網際網路視為一個「有機體」,在這個有機體中,所有加入「網格」的個人電腦都視作是該有機體的「細胞」,每個「細胞」可以提供他多餘的運算能力,當有一個「運算任務」發出後,各個節點分散了整體的運算任務,讓整個的「網格」可以發揮最大的能力來進行運算。

「網格運算」可以說是分散式運算中的一個極致運用,但是網格運算在管理上仍然是一個很大的問題,由於參與網格是一個「自由」且「自發性」的行為,因此,同一個運算任務究竟需要多少的時間可能都沒辦法事先預測,也因此,是否有更適當的方式能夠同時兼顧「分散式運算」與「集中式管理」?

「雲運算」似乎是達成上述目標的其中一個「聖杯」。

何謂雲運算呢?根據美國國家標準技術研究所(National Institute of Standards and Technology, NIST)的定義,雲運算是:
「Cloud Computing is a model for enabling ubiquitous, convenient, on-demand network access to a shared pool of configurable computing resources (e.g., networks, servers, storage, applications, and services) that can be rapidly provisioned and released with minimal management effort or service provider interaction. This cloud model is composed of five essential characteristics, three service models, and four deployment models.」(ref: The NIST Definition of Cloud Computing; NIST Special Publication 800-145; Peter Mell & Timothy Grance)

雲運算是一個具備普及性、便利性及隨選式網絡的模型,其可以存取共用的可配置的電腦資源庫(如網絡,伺服器,存儲,應用程式和服務);使用者可以運用最少的管理成本快速地與服務供應商互動。

雲運算模式是由五個關鍵特性、三種服務模型以及四種部署模型所構成。

閱讀全文 »

[案例研討] 雲端與安卓系統分析與實作-以豪小子App為例-05

六、使用案例的實現 (use case realization)-利用循序 (sequence)圖表達物件之間的互動合作-Cloud Server System

圖 12、使用案例的實現 (realization)
(點擊圖片鏈接看原圖)圖12、使用案例的實現 (realization)

    關於使用案例實現的表達意涵:

  • 可以藉由 UML 的合作 (collaboration)圖示,來表現與使用案例的實現 (realization)關係。
  • 使用案例的實現可以是程序導向或物件導向的實作方式,沒有絕對的方法。
  • 程序導向 (procedure-oriented)的實作細節可利用活動圖 (activity diagram)來表達實作的設計。
  • 物件導向 (object-oriented)的實作細節則可以物件合作圖 (如溝通或循序圖)來表達實作的設計。
  • 本例均以循序圖 (sequence diagram)來表達物件內部互動合作的實作。

閱讀全文 »

軟體思維顧問

專職軟體輔導與教育訓練的獨立顧問。輔導企業資訊單位如何有效組織系統開發與維護;輔導開發人員達成有效的專業分工。傳授如何把軟體作軟 (Keeping Software Soft)的技能,得以提昇系統的彈性/延展,並進而創造系統的再利用價值。

Personal