[實作筆記] 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)。

閱讀全文 »

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

閱讀全文 »

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 分鐘就給出範例答案啦。

閱讀全文 »

[範本] 一個最基本的 C#.NET 單元測試程式碼骨架 for VS.NET 2015

所謂的單位測試框架 (Unit Test Framework),其作用在於讓開發人員可以輕易地撰寫以「類 (Class)」為單位的測試程式,並隨時可以執行自動化的重複性測試 (automation repeatable test),以確保該單一類別的正確性。

單位測試的創始者為 Kent Beck,其理論與方法已被各程式開發語言所接受並多以開源方式 (Open Source)釋出,作為xUnit家族的單元測試框架 (unit test framework)。

多數測試框架 (如 MSTest, Junit)已直接內建於 IDE (如 VS.NET 2015, Eclipse)開發環境內,使得開發人員撰寫與執行單元性的測試程式是一件輕易的工作;自 Visual Studio 2015,尤以免費釋出的 Visual Studio Community 2015 版本,均已內建更具多功能、擴展性佳的單元測試機制。

透過 Unit Test Generator,可以:

  • 支援內建 ( MSTest)與 3rd Party (NUnit, XUnit)測試框架 (Test Framework)。
  • 依據測試框架產出對應的單元測試專案與測試程式碼骨架 (skeleton)。
  • Test Explorer 可以支援任一測試框架,只要有實現 (implement) Test Explorer Adatper 介面,如此得以執行任一測試框架所撰寫的測試程式。

底下即為個人利用內建的 MSTest 測試框架 (Test Framework)所撰寫的最基本的測試程式碼骨架 (skeleton),參考如下:

閱讀全文 »

開源免費下載-完整設計模式 (design patterns) 程式碼(C#.NET)/UML Model 檔

關於爾後我們 HSDc. 軟體設計顧問所開設的課程,除了教材內容尚無開放以外,其它包括完整可執行的程式碼、UML Model 檔,均以開源方式 (open source)免費供下載。

所有開源文件的釋出 (release),均可以透過加入 FB社團-軟體設計鮮思維 獲取最新的訊息。而所有的程式碼/UML Model,我們則是一律統一放置於 GitHub,當然在 README 文件上我們會附上基本的操作說明。

以後這些開源文件,尤其是案例程式碼,我們均會不定期持續版本更新。讀者可以透過 Git 工具隨時作同步更新。

目前提供了兩份開源文件:

另外補充關於上述設計模式 (Design Patterns)案例的說明。

在 C#.NET 程式碼部分 (Java/Spring 版本後續會另行公布),包含了完整 23 個設計模式範例;而關於 UML Model,則還增加了以周遭生活案例的塑模 (modeling),讓每一個設計模式的目的更容易理解。

關於 C#.NET 程式碼的結構部分,主要分為兩個專案 (project):一為 Web MVC by ASP.NET;另一為 Control by POCO (plain-old CLR objects)。

關於本案例的設計模式物件分層結構,可以參考下圖:

圖、圖、設計模式的物件分層結構

圖、設計模式的物件分層結構

閱讀全文 »

程式設計的招式對打練習方案-Kata

「The Clean Coder (有中譯版)」一書內所提及的「程式設計柔道場 (Coding Dojo)」的理念很有意思:

「把每一段可用來模擬程式設計問題內的解決過程案例 (case study)稱為 Kata (對打),其最終目標就是在不斷的練習當中以達純熟的直覺反應式寫碼動作。」

每一個 Kata 都必須伴隨著 TDD (Test Driven Development)、亦即測試先行的反覆測試建置。

有個 Uncle Bob (Clean Coder 原作者)提供最經典的範例:「保齡球 (The Bowling Game)」,這個練習約約要 30 分鐘 (我是不太相信這麼短 !^^),在測試階段會經歷衝突,而後在建置階段達到高潮。

我這裡提供下所查詢到的一些討論 Kata 的文章與範例:
o http://katas.softwarecraftsmanship.org/
o http://butunclebob.com/ArticleS.UncleBob.TheBowlingGameKata
o http://www.peterprovost.org/blog/2012/05/02/kata-the-only-way-to-learn-tdd/

爾後個人的實戰案例,例如「烏龜販售系統」,也打算以開源 (open-source)、簡單設計 (simple design)並整理成 Kata 的範例供學員們練習。藉此從其中學習到 Enterprise MVC、Service-Oriented、TDDRe-factoring 等觀念,透過草稿式的設計與直接程式寫碼階段來理解與應用。

軟體思維顧問

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

Personal