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

閱讀全文 »

SourceTree 使用 SSH 連結 GitHub 與載入 SSH Key 設定摘要

GitHub 為了安全性議題,已從 2021/08/13 強制要求用戶登入 (authentation) 機制只能採用 SSH 或 Persoan access token,傳統使用賬號/密碼登入方式已不再支援。可參考:「Token authentication requirements for Git operations」。

關於 PAT (Personal Access Token) 具體相關操作,可參考官網文件:「Creating a personal access token」。但該方式還要做相關的權限設定,實在麻煩,所以使用 SSH 登入只要做一次設定相關方便許多。關於 GitHub 使用 SSH 相關設定,可參考國外這篇文章,包括基本原理都有說明,值得參考收藏:「How to Generate SSH Keys for GitHub」。

已安裝好原生 Git,並使用內建的 Bash 終端機,執行「ssh-keygen」命令,如在 Win10 環境下,即會在「/Users/login-account/.ssh」資料夾內 (若為 Linux 則為 ~/.ssh) 產生公/私鑰,然後再把公鑰內容複製貼上至 Github → Setting → SSH and GPG Keys 內所新增的 Key 內容即可,就可以使用 SSH 連線,相當簡單。

如果只使用原生 Git Bash 透過 SSH 連線 Clone 遠端 GitHub 儲庫就可以正常存取了,但是若透過 SourceTree 卻需要另一番設定方可 (而且還有些繁瑣),主要原因是 SourceTree 目前版本只支援使用 PuTTY 格式所儲存的 Key,所以要嘛先透過已有安裝的 PuTTY (或 WinSCP) 設定好 SSH,否則就需在該應用程式內執行下述設定。

閱讀全文 »

微服務的內部分層結構- 洋蔥 (Onion) 架構

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

  • 基於 DDD (Domain Driven Design) 設計思維的一種架構呈現。
  • 洋蔥的中心即爲系統最爲穩固的核心 (如圖爲 Domain Model)。
  • 本質仍為三層式 (3-tier) 分層,亦即展示、應用邏輯、資料存取的分層,但特別強調相依反轉 (IoC, Inverse of Control)。

Onion Architecture 分層 (Layer)

  • Domain Model (領域模型)
  • Domain Service (領域服務)
  • Application Service (應用服務)
  • Infrastructure (基礎建設)
閱讀全文 »

微服務總體系統部署架構

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

Client (用戶端)

  • 通常爲使用者界面 (User Interface),例如網頁 (Web Page) 。
  • 用戶端可以透過 API Gateway 取得系統提供的服務。
  • 除了使用者介面外,也可以是其它裝置,例如 Mobile App,以及來自外部系統的 Request。

Identity Provider (身份辨識提供者)

  • 將來自用戶端的請求 (request) 傳遞給身份提供者,身份提供者對客戶端的請求進行身份驗證並將請求傳達給 API Gateway。
  • 通過定義良好 (well defined) 的 API Gateway,將請求轉派 (delegate) 至系統內部的微服務。

API Gateway

  • 用戶端不直接調用 (invoke) 服務,而是透過 API Gateway (閘道) 擔任進入點 (entry point),將請求轉發至適當的微服務。
  • 收到用戶端的請求後,內部架構由微服務組成,微服務通過訊息的相互傳遞,以處理用戶端請求。

使用 API Gateway 的好處

  • 對所有的微服務形成良好的封裝 (encapsulation),內部微服務的變動不會影響到用戶端。
  • 可以將外部通用的協定 (protocol),轉換為 Intranet 內部所使用特定的通訊協定。
  • 可以提供系統橫切 (cross-cut) 的非功能性需求,例如安全性 (security)、負載平衡 (load balance) 等。

Static Content (靜態內容)

將微服務處理後的靜態內容,部署至雲端平台的存儲機制,該機制可以經由內容傳遞網絡 (CDN, Content Delivery Network) 傳回給用戶端,進而可以提供效能、可擴展與較低成本網路傳遞。

Service Discovery (服務檢索)

提供一種目錄服務 (directory service) 的方式,而可以透過多樣化的檢索方式來取得所對應的微服務。

System Management (系統管理)

負責系統節點 (node) 的負載平衡,以及檢測故障 (failures)。

微服務 (Microservices) vs 單體式 (Monolithic) 系統比較

MicroservicesMonolithic
部署 (Deployment)應用程式基於特定的業務能力界定多個微服務,每個微服務爲獨立可各別被部署應用程式只有一個單元的主體
耦合性 (Coupling)每個微服務已元件化,彼此間的溝通只透過 API 連結,因而形成良好的寬鬆耦合 (loose coupling)功能模組之間沒有良好的隔離而造成緊密耦合 (tight coupling)
延展性 (Scalability)可以視微服務的負載情形而各別擴展系統資源只能對系統整體採以複製 (clone) 的方式擴展
開發 (Development)可以依微服務的性質採不同的實現技術;每個微服務的實作團隊可以並行分工開發只能選擇一種特定的實作技術;團隊的分工大都採以模組的切割,或依據分層的技術,需要較高的專案管理 Effort
維護性 (Maintenance)每個微服務可以個別獨立建置、部署與維護由於只有單體式的系統,所以管理與維護會依系統規模度而有着等比複雜度的提昇
適用系統性質平台 (Platform)、產品 (Product)專案 (Project)
適合系統規模大型涵蓋多個業務範疇 (如 ERP) 的系統小型團隊建構規模較小的系統
適合雲端服務非常適合系統規模越大,就越難以部署至雲端平台上
系統開發難易度• 需有總體架構規劃,架構師 (Architect) 或架構團隊需有效界定微服務的邊界 (Bounded Context),以及制定微服務間的 API 協定
• 微服務平行分工的開發團隊需高度正向的密切溝通,持續整合不僅涵蓋技術,也包括人
因大都採以資料導向 (data oriented) 的開發模式,所以初期開發容易;但隨着系統規模度與變動性的議題,很容易導致複雜度的提昇,系統易淪於僵化而難以維護

微服務特點與主要特徵

微服務 (Microservices) 特點

  • 每一個微服務均視爲是一個小型的系統。
  • 微服務各自擁有自己的私有倉儲 (資料庫)。
  • 微服務之間的互動是透過 API 的介接。
  • 每一個微服務是獨立的個體,所以可以爲各自的微服務採用不同的實作技術與系統的建置、部署及維護方式。

主要特徵 (Characteristics)

  • 經由服務 (service) 的元件化 (componentization)。
  • 圍繞業務能力 (business capability) 的組織 (organized)。
  • 分權化的治理 (Decentralized Governance)。
  • 寬鬆耦合 (loose coupling) 的連結性 (connectivity)。
  • 基礎設施的自動化 (Infrastructure Automation)。

閱讀全文 »

軟體思維顧問

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

Personal