C#.NET Core CRUD 基本資料維護實作範本 – 三層式架構以及可以切換 E.F Core 6 與 ADO.NET 實作

已經整理好 C#.NET Core CRUD (Create,Read,Update,Delete) 基本資料維護的實作範本,並已上傳至 Github 供下載:https://github.com/kenming/petstore-crud-template-csharp

關於該範本如何執行 (包括跑單元測試)、主要引導功能、開發工具與建置、類別圖展示等,已具體詳細寫在 README.md 文件。

建議要執行該應用程式前,先更改下 Sqlite 資料庫檔案路徑,然後先執行測試專案內的所有單元測試方法

關於該範本所涵蓋的一些設計思維與所對應的實作問題,版友們可以提問討論與分享想法。關於程式碼的實作細節與設計思維,我還會另撰寫文章詳細說明。

後續的版本演進我會再加上:

  • 多個表格關聯的 CRUD 實作。
  • 使用 Mock 應用在單元測試,隔離 Service 類別依賴具體 Dao 的資料庫存取。
  • 使用 Vue UI 框架整合本範例。

Brief Description

網路上看到關於基本資料維護的 CRUD 範例幾乎都是資料導向 (data oriented) 的寫法,也就是把 MVC Controller 與 資料存取綁在一起。現實上稍有規模的專案採用這種開發模式會導致系統的複雜度提升,不容易應變。

花了幾天時間撰寫了 C#.NET Core (前年有寫過 Java Spring 的版本) 關於單一資料表的 CRUD 程式碼範本,這是一個完全符合三層式架構的應用程式,同時我這個專案範本可以切換 E.F Core 與 ADO.NET 資料庫的存取實作。

關於 Java/Spring 版本,我則打算再重新改寫,架構當然與 C#.NET Core 是一樣的,只是實作的細節必然會調整下。資料庫的存取方式則打算同時提供 JDBCTemplate 與 MyBatis 的 CRUD 範本。

Features

  • 提供開發三層式 (Presentation -> Application Logic -> Datasource) 架構的 CRUD 實作範本
  • 同時提供 E.F Core (Entity Framework Core) 與 ADO.NET 資料存取方式,並可以切換資料庫存取的實作
  • 實作 E.F Core 與 ADO.NET 的 DAO (Data Access Object) 均各自有撰寫單元測試程式 (Unit Test Code)
  • 專案內嵌 Sqlite,並使用兩種實作方式:
  • File-based 為正常存取用的資料庫,提供給 View 操作
  • Memory-DB 應用在單元測試的 Create, Update, Delete ,避免影響到正常資料庫的存取行為

Development

閱讀全文 »

如何從巨觀的需求流程分析,可以直覺無縫的橋接至程式寫碼?

本文同步發表於「FB 軟體設計鮮思維」社團。

這裡採用個人所發表關於需求分析的「MSS」與 程式寫碼的「SSD」三層次分析與實作方法。

需求分析階段的 MSS 三層次

關於 MSS,可以參考原來寫的這篇:「大業務流程塑模的MSS三層次原則」。

o M(multiple) Process。
o S(ingle) Process。
o S(ystem Function)。

    以「請購-採購」作業流程 (business process)為例:

  • Multipole Process:「請購」與「採購」兩個作業流程的表達,焦點擺在「請購」作業內部的一連串活動 (activity)分析。
  • Single Process:「請購」作業流程的內部活動表達,焦點擺在「進行供應商評等及比價」的系統功能對應。
  • System Function:「採購」資訊系統的系統功能界定 (利用使用案例)。焦點擺在「比價」的系統功能實現 (realization),實現的步驟主計有「列出廠商資訊」、「評等列出優先順位供應商」、「儲存比價交易紀錄」。

程式寫碼的 SSD 三層次實作

可以參考「實作 Enterprise MVC 巨觀結構的 POC-觀念篇」內關於「控制類別」的說明。

o S(ubject) 主題。
o S(TEP) 實現主題的步驟。
o D(etail) 實作每一步驟相關的細節 (欄位明細與業務邏輯)。

    承接上述例子關於「比價」使用案例的實現。

  • Subject:「比價」使用案例-對應至「比價Control」控制類別。
  • STEP:「比價Control」類別內的 Function (Method)對應為:
    「ListSuppliers()」、「ComparativePrice()」、「SaveComparativePriceTransaction()」。
  • Detail:「ListSuppliers()」列出廠商的清單與欄位資訊From資料庫;「ComparativePrice()」處理比價的邏輯與評等;「SaveComparativePriceTransaction()」儲存本次比價的交易結果至資料庫。

Visual Studio 使用 Quickfix 重構工具簡單說明與錄影操作示範

參考 使用 Visual Studio Quickfix 重構工具的幾個主要類型與範例

這裡提供程式碼練習案例 (放於 Github),可以參考上述網址的操作說明或後述的錄影操作示範。(其中有改寫幾個案例,每一個案例均可透過 Console 程式執行。)

重構範例的操作錄影教學與簡單說明則已發布於「FB 社團—軟體設計鮮思維」:

C# 實作共用變數 by Singleton – 以交易系統登入連線為例

問題

股票期貨交易系統的登入驗證連線,必須隨時保持連線狀態 (connection state),也就是必須設計為 Stateful (有狀態),並於盤中需隨時得知連線情形,若斷線則系統應該要能通知用戶做重新登入的動作。

如果有多個表單 (View) /多個類別需在執行期間 (run-time)可以察知共享登入的連線狀態,該如何實現?

解決方案

共用變數類別

最簡單直覺的方法,設計一個共用變數 (global variables)類別,並保存需要在多個應用程式/類別之間共享的狀態/值。

可以參考此篇的作法:Global variables class

閱讀全文 »

[備註] Visual Studio 2017 跑 x64 單元測試的設定

最近申請到「群益報價/下單 API」,也下載了 C#.NET 的範本,但卻是用 Visual Studio 2010 編譯的專案,花了一個多小時手動編輯 .csproj,總算可以在 Visual Studio 2017 開啟執行

不過範本寫得非常之亂,典型的全把所有邏輯寫在 Windows Form 類別。實在看不下去,準備把一些主要呼叫的 API (Login,下單,報價) 重整下,從 Windows Form 全抽離出來,並撰寫單元測試 (unit test) 方便測試。

群益API 是採以 COM 相對底層機制所撰寫的,使用前要先註冊該元件 (SKCOMLib)。我直接採用 x64 64位元的處理器架構,完全不考慮 32位元,還好群益都有提供。

程式撰寫挺簡單,但執行單元測試卻出了問題,只要將「目標平台 (target platform)」改為「x64」就會出現一些很怪的錯誤訊息。原來以為是呼叫 COM 出了問題,甚至打電話問了群益的資訊部人員,但他們竟然說沒聽過單元測試,程式沒有從 Form 開始就看不懂。挖哩,不過他們確信 COM 元件沒有問題,看來還是出在環境設定上。

查找解決文與 Try-Error 大半個下午,總算,就是只要在 Visual Studio 2017 選單「測試」→「測試設定」→「預設處理器架構」改為「X64」就 OK 啦!

Visual Studio 2017 跑 x64 單元測試的設定

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

安裝與設定參考文件,主要有兩篇:

閱讀全文 »
軟體思維顧問

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

Personal