發表文章

目前顯示的是 2022的文章

軟體架構設計:無題

圖片
軟體架構設計:無題 Logo 圖片、六角架構 取自:https://reflectoring.io/spring-hexagonal/ 前言 為什麼叫做無題?因為軟體架構設計是一個相當龐大的主題,也不可能在一篇文章中談完,先前我也曾寫過許多架構設計系列文、包括領域驅動設計 DDD 與 整潔架構 Clean Architecture 與如何在以上的軟體架構為基礎來落實 TDD。 今天,我在以更廣泛與更實務的角度來探討軟體的架構設計,文之中也會搭上我這些年來所設計的框架、Framework 並對上也是這些年後來所讀的相關書籍、像是 DDD 領域驅動設計、Uncle Bob 的 整潔架構 Clean Architecture、還有正在讀的【Get Your Hands Dirty on Clean Archiecture】,這這些書的洗禮之下,也在下面的文章中裡探討缺失、改善的方式,希望對於工作中正在進行架構設計或是正在進行專案規劃,但想要有個架構設計的資料可以參考的程式設計師,那麼或許您可以參考文章中的資料,或許對您有所幫助。 階層式架構設計的隱憂 圖(一)、常見的階層式架構     傳統的階層式架構幾乎伴隨著我們好幾 10 年了,相信讀者不陌生,許多的老系統,包括我在 18 年前在流通業開發的幾個系統、以及後來10年前在X創開發設計的好幾個政府機關的系統也都是階層式架構設計。 究竟什麼是階層式架構?它與更早期講的三層式架構有些不同、比如 Windows DNA 那又是更早的跨機器架構,注意了,對是『跨機器』的軟架構,像是微軟早期 (DCOM, Distributed Component Object Model) 所以 DCOM 加上 Distribute 表示快機器、而 COM 就是跨行程。 這是早期的分散式環境,套用到現今,許多人想到的 Microservices/Docker.. 微服務等容器環境,這在跨機器的場景非常類似,但是 DCOM 需要完整的 OS 作業環境的支援、而 Microservices 微服務拜後來【VM 虛擬化技術】又再進階到【OS 作業系統虛擬化技術】之賜,使的應用程式可以包裹在更輕量化的容器環境之中,沒有作業系統啟動速度慢、占用系統支援較多等問題、更適合建構需要橫向擴展的 Cloud 雲端運算的環境中。 原歸正傳,所

關於 Visual Studio 支援 IWizard 的範本套件開發

圖片
關於支援 IWizard 的範本套件開發 關於 Visual Studio 範本 以下提及的 Project Templates = 範本 小弟蠻多文章、線上課程、或者在社團分享許多關於 Visual Studio 範本開發的相關資源,也成立裡書社團【台灣 Visual Studio Extensions 套件開發俱樂部】。 事實上、Visual Studio 如果是單純的 範本開發 也就是 C# Project Templates 最簡單的方式就是(匯入/匯出)範本,但是這完全沒什麼彈性 與 擴充性可言,更不用說你想做出像互動式精靈甚至 Generate Code產生專案程式碼骨架等等,這就不是單存範本能夠做到,這就得透過 VS IDE/envdte/IWizardTemplates 才能夠做到,也就是得使用一些 Visual Studio IDE 的一部分功能才能夠做到。 為 Project Templates 加入 Code Generate 的功能 在我最早期的 MyORM 裡即提供一種動態入 Entities/DbContext 的功能、甚至我能 Generate 自己框架的 Source Code 進來。 IWizard 很多人都知道 IWizard,這裡就不多談,它只是進入互動 Project Templates 的一張門票而已,它讓你的 Templates 跟 IDE 建立互動的機制 + 取用 IDE 的功能,它的功能也不只如此,不過若您不清楚如何建立支援 IWizard 的 Project Templates 可以參考我的線上課程: 團隊開發系列-設計符合團隊的範本精靈 (Project Template) 課程連結: https://hiskio.com/courses/192/about?hi=MNJ7EJRV3Z4L&s=tc 。 .NET 6 中的範本開發 由於 .csproj 專案格式的改變間接影響到 Project Templates 的開發,怎麼說呢?因為 Project Templates 為 Visual Studio 擴充性的一部份,這其實從 VS2010 開始,Logo 圖其實就有說明這一點了。 安裝了 Visual Studio 擴充功能後,你可以找到『延伸模組』 且會有【VSIX Pro

從整潔架構談自定義 NuGet 套件規劃與使用

圖片
從整潔架構談自定義 NuGet 套件規劃與使用 前言 我們在規劃框架與底層元件時,免不了會將框架的底層元件、像是你 UI 的 BasePage、或者是 MVC 中你自定義的 ViewPage 的 BaseViewPage 又或者是你自定義框架 Framework/Platform 的底層運作包裝成 NuGet 套件供使用該功能的各系統負責人使用,將特定功能包裝成 NuGet 套件再重複使用某些功能時非常的方便,它可能方便到有種魔力,甚至會讓你想將許多功能都包裝成 NuGet 套件以達到重複使用的目的。 問題的發生 現在問題來了,這也是我在客戶端發現到的一個現象。 客戶:Entity Framework 的資料存取功能適合包成一個 NuGet 套件嗎? 這裡問題來了... 我說:請問這個是指這個套件內容會包含 OR-Mapping 的 Entites/Repository 等內容嗎?😯 如果是,那這個可能不適合包成一個 NuGet 套件。(蝦~什麼?) 客戶接著會說:但是 Entity Framework 本身也是個套件。 我說: Entity Framework 本身由套件來提供這個當然沒有問題,但是你的 Repositories/Entities 以上那已經跟商業有關了? 客戶更疑惑了:我們在開發框架時,比如說我們的 Business Object 的 Base 不是就是由 NuGet 套件提供的嗎? 我說:你說的沒有錯! 但是你現在是把 DataAccess Layer 包成了 NuGet 套件了,當然~沒錯你會認為 DataAccess 算是 Infrastructure 這的確是沒錯!但是這裡的 Infrastructure 應該算是(與你的 Domain/Business 無關的部分)也就是應該不包括你的 Entities 都可以包進 NuGet,那是不正確的。 這時客戶會說,這好難界定阿?老師你說 DataAccess 就是 Infrastructure,但是又不能包進 NuGet,那到底該怎麼做啊? 🙁 當時,我我很即興的繪製一個【簡圖】來說明(而現在我將這簡圖用 PowerPoint 來畫更專業點的,若想查看原本的簡圖可看我在臉書的 PO 文:https://www.facebook.com/groups/361804