Blog

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

*** 本文同步發表於 FB 社團-軟體設計鮮思維 ***

關於 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)。

Enterprise MVC 主要元件責任界定

閱讀全文 »

[美食推薦] 滿滿盡是配料好是特別的泡麵-螺螄粉

第一次聽到這怪異的泡麵名竟然是前幾天看到知名的美籍台灣女婿 Youtuber 小貝在他這集-跟我老婆一起吃螺獅粉/辣泡麵介紹後才知道有這麼神奇卻其實早已大受諸多部落客歡迎的螺螄粉泡麵。

小貝的影片很有魔力,總是能感受到他滿滿的熱情與亢奮,所以廠商找他業配就對了啦。從影片知道可以在蝦皮打關鍵字「螺螄粉」,然後看銷量找第一名購買就好。這次共花了 NT$1080 買了10碗各類不同口味,以及一些配料 (如青木瓜絲、辣蘿蔔),不到兩天就送到 7-11 取貨付款了。
螺螄粉

盡量各種口味都選買來嚐嚐看,至於最受歡迎的好歡螺與螺霸王就再多買一碗。
螺螄粉

閱讀全文 »

[簡單開箱] RetroGame 懷舊掌機入手

上個月在 FB「DIY電玩主機改造社」,跟團購買了一台懷舊掌機-Retrogame,要價 NT$1580 多附一片鋼化膜。這也是繼近8年前購買的丁果 A330,詳見-[敗家] 超強悍的山寨遊戲模擬掌上機-丁果A330,所購入的掌機。

沒辦法,我太愛懷舊遊戲了。諸如街機、SFC、GBA/GC、Openbor ... 等各類透過模擬器 (Emulator),都可以在小小的掌機內暢玩,在外時可以排遣無聊,調劑下身心,也不用如手機電玩那樣太過絢麗也不好操縱,掌機自身帶控器手把與按鈕,相當便利。

為了這台掌機,我加買了兩片 CLASS10 的 MicroSD 卡 (對岸稱 TF卡),一為 64G,另一為 128G,規格為 UHS-1 Class 10,但發現到使用 64G 已是綽綽有餘。

掌機本身包裝很精簡,附了一條 AV 端子線與供充電與連線應為 Mini USB 比較奇怪的規格 (現幾乎都是 Micro USB)。
RetroGame 掌機

閱讀全文 »

決心走出白漫城-使用 MO 重新安裝 Skyrim SE

Skryim 是神作,它的開放世界觀、自由度之高,以及起碼數萬種類模組 (還在持續增加),絕對是讓其奠立為永垂不朽的遊戲鉅作沒有之一。

我從 Skyrim 傳奇版 (32bit),直到 Skyrim SE (64bit)版,最少有五年的時間,來回安裝眾模組 (MODs)起碼有十數次之多了。但早期 32bit 版本最多只能支持 4GB 記憶體,造成很容易 CTD 跳出;而 SE 版則是 2016/10 才推出,初期模組數量支援不多,還有最重要的 SKSE (腳本擴展工具)前一年都還未能釋放出來,直至這兩個月總算推出相當穩定的版本 (目前為 2.0.7)。

以前只要一有 CTD 跳出,就導致我失去繼續玩的動力。事實上,花在安裝模組的時間,遠比實際玩遊戲的時間多太多太多了,難怪乎玩友們都說玩了 Skryim 那麼多年,還是仍停留在「河木鎮 (新手城鎮)」與「白漫城 (第一個主城)」。

嗯,這次因為穩定版的 SKSE 64bit 釋出,還有這篇超級超級棒的 MODs 整理文:【心得】個人MOD使用、排序、管理 (持續更新),所有具代表性的 MOD 且已分類好及中文化的檔案提供直接透過谷歌磁碟下載,真是太有熱忱了,造福廣大台灣用戶玩家。

照著該文的安裝指引,另外我是使用 MO (Mod Organizer) 來安裝與管理模組的。 (MO 真是神奇的工具,它創始了以虛擬整合模組的方式,使得很容易調整與管理模組。) 這樣陸續安裝了兩、三個星期左右,總算開啟了新遊戲,體驗在這天際廣袤無垠的上古世界冒險解任,瀏覽觀賞這豐富多樣的美麗景色 (安裝各類景觀、天氣等模組後)。

閱讀全文 »

軟體工程師與軟體設計師有什麼不同?

*** 本文同步發表於 FB 社團-軟體設計鮮思維 ***

看到這篇文章:「What’s The Difference Between a Developer and an Engineer?」。這篇文章試圖比較 "軟體工程 (engineer)師" 與 "軟體開發 (developer)師" 的不同點與各自所需技能為何。

Software Developer 我覺得也可以稱為 Software Designer,同為設計原意。

若是我個人的解讀,軟體工程師比較著重在 "How-to" 的實作面。他會深入探究各類技術框架與工具的使用,舉凡 UI端 Javascript-based 框架、底層系統層級的技術框架、甚而包括了 3rd party 的 utiltiy 類型的 library 等;同時還有各種開發工具的精通。

軟體設計師,則會比較關注在 "What & Why" 的思考創意面。文內有提,設計師更會加強在心智上的修煉,包括自我學習、探討、觀察、閱讀等軟性功夫上 (不一定馬上就能應用到實務工作上)。

閱讀全文 »

Java Coding Style 內的 at-clauses 是什麼意思?

今天下午在龍潭某半軍事院所教授「軟體結構設計」系列課程,案例主要以 Java/Spring 來實作。

課後結束,該單位一位單純又可愛的年輕正妹送我出門 (視為廠商單位需內部人員陪同檢查證件),然後順便在會客室就近問我些問題 (好認真有心的女孩呢,假日還會窩在住宿處練習寫碼我提供的實作案例,值得肯定鼓勵)。

不過她問的問題反而不是我課堂教授的內容,是針對 Java Coding Style 某一部份的定義她不太了解。

啊,我極少重視這種所謂 "Coding Style" 議題,大概也只是縮行、空白行,盡量讓 method name、參數、回傳值等給予有意義的命名,整個敘述讀起來通順即可。

不過大型單位會要求這些也不是沒道理,總還是希望有所謂共同的寫碼基本規範 (不過反而沒要求 Method 陳述要控制在 30 行以內,這點期望能加進去)。

嗯,她問我的問題是 :
當全部的「at-clauses 」都出現時,其標準的使用順序為 @param 、 @return 、 @throws 、 @deprecated ,而這四種類型都不會為空。當一個「at-clauses」無法以單行描述完畢時,其續行該要以 @ 為基準做四個(或更多)空白的縮排。

這,當下我肯定不會,所以承諾她說晚上回家找我的好哥們請教。然後就剛沒多久,問我那位哥們不到 10 分鐘就給出範例答案啦。

閱讀全文 »

軟體思維顧問

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

Personal