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

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

閱讀全文 »

聊聊關於 UML 輔導個案的二三事

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

UML System Sequence Diagram

前兩個星期有位上過前一期「軟體架構師」課程的學員,他在某大金融單位擔任技術職PM,特地利用週末時間到我家附近,請教我關於他利用 UML 所繪製的設計圖問題。相當認真,所以我很願意陪他一同討論軟體相關議題,順道一同在肯德基吃午餐。總共花了約兩個來小時吧,該學員還要去參加他的讀書會,真是有夠認真啊,不過起碼有討論出一個比較具代表性的使用案例其實現的主要程序描述。

畫出來是否正確或合理與否是一回事,至少他肯利用 UML 表現出他的設計思維就很值得肯定,這才有機會可以指指點點與討論的。

他只畫了使用案例圖與某一結構設計的類別圖,因爲有公司機密問題,這裏就不方便貼出他的原稿。我只就他的設計給予一些建議與修正,並利用他在 Mac 所使用的 UML 工具繪製出來。

關於 DDD (Domain Driven Development) 微服務的結構設計議題

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

最近在線上輔導了一位 技術職PM 結構設計的實現 (Realization)議題,他傳給我 DDD 的架構圖,覺得在「Domain Service」與「Domain Model」的責任界定上,觀念不是很清楚。

嗯,其實這所謂的 DDD (Domain Driven Development) 架構圖根本就是典型 3-tier (Presentation-Application Logic-Data Source) 分層結構呈現爲圓形的剝洋蔥層次而已,越是內層 (Domain Model) 越代表爲系統的核心。
DDD Onion Architecture Diagram

工程師從這張圖往往會認爲「Domain Model」是最重要的核心觀念。是這樣沒錯,但對以「需求爲導向」的專案開發性質,它卻反而沒那麼重要!況且結構設計的基礎功夫要很紮實,封裝-介面-多型 諸多「虛」的設計觀念確實能充分了解並能整合活用,沒有花上 5-10 年以上功夫,是不容易應用在現實的系統開發上的。相對於此,「Domain Service」對現實的專案開發可是更切實際,且結構設計上的觀念也會比較容易入手。

閱讀全文 »

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

本文同步發表於「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()」儲存本次比價的交易結果至資料庫。

「軟體需求分析與塑模」- 單一作業流程的塑模

本文收錄於 我的電子書「軟體需求分析與塑模 – 第二章、企業流程的分析與塑模」。

描述與紀錄單一作業流程內部的一連串活動,使用 UML 活動圖 (activity diagram) 是最為適切的。

依據 UML 三巨頭的論述,活動圖主要的目的在陳述活動與活動之間的流程控制的轉移 (control flow transition)。
Activity diagrams emphasize the flow of control from activity to activity. (《The Unified Modeling Language User Guide》, Grady Booch, James Rumbaugh & Ivar Jacobson, 1999, pp. 257)

這裡所謂的活動,可以指企業的活動,也可以指應用程式中的某個特定功能。

不過一般來說,由於「活動」的定義並不如「物件」那麼明確,因此,在進行系統設計時,一般比較不傾向於利用活動圖來表達應用程式的結構 (採用物件模型較為恰當);也因此,活動圖通常會比較適合用於表達企業活動的工作流程關係。除此之外,由於活動圖非常類似傳統的流程圖 (flow-chart),因此,活動圖也適於表達細部程式的程序性結構。

參考下圖,藉由一個請假作業流程來說明 UML 活動圖的主要圖形元素。

圖、請假作業流程活動圖的基本圖示語法

 

閱讀全文 »

軟體技術人員最愛卻也是尾大不掉的萬用 Database Manager 物件

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

上星期我在教授 TDD.NET 測試驅動開發課程。其中有位學員分享他們公司會計系統的部分程式碼 (沒有機密性議題),想知道這該如何撰寫單元測試 (Unit Test Code)。

我先用 EA (Enterprise Architect) UML 工具掃描程式碼反轉為 類別 (Class) 圖,老天!數百個 Windows Form (每一個 Form 他們稱為 Report) 全連接到一顆共用的 DB Manager,封裝了基本的 CRUD 行為,再存取資料庫。剛掃進來時還真嚇了一跳跳,那個 Form 的連線,有如積體電路般密密麻麻的共同連接到如同就是 CPU 地位的 DB Manager!

2tier universal db manager

這肯定就是典型技術人員的傑作,用許多稀奇古怪的實作方式,讓所有的表單 UI 程式,傳進來 SQL 敘述,然後再去存取資料庫。看似方便簡單,但這顆萬用的 DB Manager 已經被約束了特定的實作技術與特定的資料庫,所以當然無法抽換,原來他們使用 ADO.NET 的連線,現在是不可能換成 Entity Framework;不僅如此,內部程式碼的擁腫肥大,當時的技術人員一離開,幾乎達到無法維護的地步。

閱讀全文 »

軟體思維顧問

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

Personal