[實作筆記] ASP.NET Core Identity 2.1 – 安裝與設定(一)

主要是為了方便授課上講授 TDD.NET 如何應用 Mock 隔離測試的觀念,所以打算藉由 ASP.NET Core Identity 2.1 驗證與授權 (Authentication and Authorization)的機制併整合訂購系統 (核心邏輯/資料庫存取位於另一專案)的案例,來展示 單元測試 (Unit Test)搭配 Mock 隔離的程式碼範例。

另外為了測試資料庫方便可攜供學員可以直接使用,所以打算不再使用具名的 SQL Express 檔案 (連線字串問題,多個專案要指定絕對路徑,不方便複製),而只使用 SQL Express LocalDB (預設位於 C:\使用者\使用者帳號目錄內),然後再以 Code First Migration 方式與 Seed Data 方便初始建置資料庫表格與測試資料,這些留待後續系列文章再作說明。

本系列文章並非是完整的 Step by Step 教學文,而僅是一份實作筆記,主要記錄了實作過程中一些重點摘要。同時也提供了一份程式碼範本,供個人以及對相關議題有興趣的讀者參考。

程式碼範本以 Git 版控儲存於 Github 儲庫:kenming/aspdotnet-core-identyity-2dot1-practice-note
每一個階段會標注 Tag 標籤方便提取研究與切換版本。

先簡單說明下 ASP.NET Core Identity,它是微軟所提供被歸為 ASP.NET Web 端的一個「會員 (Membership)」系統,提供給應用系統開發人員方便具有登入 (Login)驗證名稱與密碼的機制。它很明顯是 Client/Server 的 2-tier 分層方式所開發的系統,但還好因為 Login 這類機制係屬於「非功能性 (Non Functional)」需求,所以也不至於會干涉到應用系統關於「功能性需求 (如處理訂購、追蹤訂購等系統功能)」的耦合 (coupling)。未來可以全部抽換掉 Identity 而不影響到應用系統的主結構 (當然還是要稍稍花一些整合設計的心思)。

個人仍覺得 ASP.NET Identity 即便到 2.1 版本,但安裝與設定程序仍嫌繁瑣,而且從 1.X、2.0 到 2.1,每一次的安裝與設定方式大都不一樣,預期後續版本仍會有持續的變動震盪。所以更顯然絕對不要撰寫與問題領域 (problem domain)相關的邏輯在該專案內,這點從個人後續提供的範例就可以看到如何避免。

本篇文章先著重在如何安裝 Core Identity 2.1,然後新增「Scaffold Identity Item」,並修改些預設的登入選項參數 (如密碼長度),然後執行預設的首頁 (index)並選擇註冊 (register)帳號並執行登入 (login)。

閱讀全文 »

闡述軟體架構師素養的絕佳古文-柳宗元「梓人傳」

軟體架構師 (Architect) 一詞,雖是源自於國外建築產業的關鍵術語,甚而建築業大師 Christopher Alexander 的著作:「The Timeless Way of Building」(國內翻譯書為「建築的永恆之道」」,更是被軟體業界奉為設計模式 (Design Pattern)之父。不過,關於軟體架構師應具有的素養,卻是更早可以從「古文觀止」其中一篇:柳宗元所著「梓人傳」,早已道盡成為軟體架構師所需的技能為何。

這裡節錄此篇古文,並引用國內 C++ 大師早已所翻譯部份文言為白話,可以確實好好品味欣賞、一讀再讀反覆玩味思考的。

裴封叔之第,在光德里。有梓人款其門,願傭隙宇而處焉。所職,尋、引、規、矩、繩、墨,家不居礱斲之器。問其能,曰:「吾善度材。視棟宇之制,高深圓方短長之宜,吾指使而群工役焉。舍我,眾莫能就一宇。故食於官府,吾受祿三倍;作於私家,吾收其宜大半焉。」

他日,入其室,其床闕足而不能理,曰:「將求他工。」餘甚笑之,謂其無能而貪祿嗜貨者。

其後,京兆尹將飾官署,餘往過焉。委群材,會群工,或執斧斤,或執刀鋸,皆環立向之。梓人左持引,右執杖,而中處焉。量棟宇之任,視木之能舉,揮其杖,曰:「斧!」彼執斧者奔而右;顧而指曰:「鋸!」彼執鋸者趨而左。俄而,斤者斲,刀者削,皆視其色,俟其言,莫敢自斷者。其不勝任者,怒而退之,亦莫敢慍焉。畫宮於堵,盈尺而曲盡其制,計其毫釐而構大廈,無進退焉。既成,書於上棟曰:「某年某月某日某建」。則其姓字也。凡執用之工不在列。餘圜視大駭,然後知其術之工大矣。

繼而嘆曰:彼將舍其手藝,專其心智,而能知體要者歟!吾聞勞心者役人,勞力者役於人。彼其勞心者歟!能者用而智者謀,彼其智者歟!是足為佐天子,相天下法矣。物莫近乎此也。彼為天下者本於人。其執役者為徒隸,為鄉師、裡胥;其上為下士;又其上為中士,為上士;又其上為大夫,為卿,為公。離而為六職,判而為百役。外薄四海,有方伯、連率。郡有守,邑有宰,皆有佐政;其下有胥吏,又其下皆有嗇夫、版尹以就役焉,猶眾工之各有執伎以食力也。

彼佐天子相天下者,舉而加焉,指而使焉,條其綱紀而盈縮焉,齊其法制而整頓焉;猶梓人之有規、矩、繩、墨以定制也。擇天下之士,使稱其職;居天下之人,使安其業。視都知野,視野知國,視國知天下,其遠邇細大,可手據其圖而究焉,猶梓人畫宮於堵,而績於成也。能者進而由之,使無所德;不能者退而休之,亦莫敢慍。不炫能,不矜名,不親小勞,不侵眾官,日與天下之英纔,討論其大經,猶梓人之善運眾工而不伐藝也。夫然後相道得而萬國理矣。

相道既得,萬國既理,天下舉首而望曰:「吾相之功也!」後之人循跡而慕曰:「彼相之纔也!」士或談殷、周之理者,曰:「伊、傅、周、召。」其百執事之勤勞,而不得紀焉;猶梓人自名其功,而執用者不列也。大哉相乎!通是道者,所謂相而已矣。其不知體要者反此;以恪勤為公,以簿書為尊,炫能矜名,親小勞,侵眾官,竊取六職、百役之事,聽聽於府庭,而遺其大者遠者焉,所謂不通是道者也。猶梓人而不知繩墨之曲直,規矩之方圓,尋引之短長,姑奪眾工之斧斤刀鋸以佐其藝,又不能備其工,以至敗績,用而無所成也,不亦謬歟!

或曰:「彼主為室者,儻或發其私智,牽制梓人之慮,奪其世守,而道謀是用。雖不能成功,豈其罪耶?亦在任之而已!」

餘曰:「不然!夫繩墨誠陳,規矩誠設,高者不可抑而下也,狹者不可張而廣也。由我則固,不由我則圮。彼將樂去固而就圮也,則卷其術,默其智,悠爾而去。不屈吾道,是誠良梓人耳!其或嗜其貨利,忍而不能舍也,喪其制量,屈而不能守也,棟橈屋壞,則曰:「『非我罪也』!可乎哉?可乎哉?」

餘謂梓人之道類於相,故書而藏之。梓人,蓋古之審曲面勢者,今謂之「都料匠」雲。餘所遇者,楊氏,潛其名。

閱讀全文 »

整合測試還是單元測試比較有價值?

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

看到國外某作者的一篇論述:「Lean Testing or Why Unit Tests are Worse than You Think」。這篇文章我瀏覽了兩遍,思考原作者從什麼樣的角度來看待所謂的單元測試 (unit test)。

文內有提,他純粹從經濟 (economic)的觀點來看待測試,然後接著從三項因子:成本 (Cost)、速度 (Speed)、信心 (Confidence)來比較 整合測試 (integration test) 與 單元測試 (unit test)的價值。

他的結論是認為:整合測試相對來得有價值許多。🤔

然後接著他再用 投資報酬率 (ROI, Return on Investment)與 程式覆蓋率 (Code Coverage)來佐證 整合測試 的高投資率。

這就讓我更肯定了,原作者是站在專案經理人 (PM, Project Management)的角度來看待整合測試,PM 最是偏好用指標來衡量投報率與顯性價值等。

問題是,投報率、覆蓋率等這些指標,是極難衡量隱性的因子與其所創造的價值啊! 試想想,該如何衡量軟體產品的彈性度、擴展性與維護性議題呢?

再則,整合測試與單元測試根本是兩種不同的構面與不同角色的人所負責的:

o 整合測試:產品釋出 (release)前涵蓋所有元件的測試,一般由 QA 品管專職人員擔任。

o 單元測試:系統開發期間對必要 (essential)性類別 (如 控制物件、資料存取物件、企業物件等)的測試,這必然由撰寫該類別的開發人員負責撰寫,不得假手他人。

閱讀全文 »

實作 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 主要元件責任界定

閱讀全文 »

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

*** 本文同步發表於 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