部落格最新文章
分享技術與日常生活
Laravel 轉 C# 的概念對照：Repository、Middleware、DI 與 EF Core 實戰指南
前言在 Laravel 專案裡，如果一百個後台列表都有相似的篩選、排序與分頁，我們可能會建立一個共用 Repository，讓大家從同一個入口取資料。轉到 C# 後，卻常看到另一種建議：直接使用 EF Core，把查詢條件抽成 IQueryable<T> 擴充方法。兩邊都在解決重複程式碼，差異到底在哪裡？ 類似的疑問也會出現在 Middleware、Service Provider、Model、Event 與 Validation。熟悉 Laravel 的經驗很有用，但遷移時需要重新確認三件事：這個元件負責什麼、活多久，以及在哪個時機真正執行工作。 這篇以 ASP.NET Core 與 EF Core 為核心，整理這些概念的對應與實務取捨。
C# 架構實戰比較：同一個訂單 API，三層、DDD 與垂直切片怎麼選？
前言假設今天要用 C# 寫一套訂單後端，包含建立訂單、查詢、付款狀態更新與取消訂單。採用三層架構，可以從 Controller → Service → Repository 開始；採用 DDD，可能會出現 Application、Domain、Infrastructure；採用垂直切片，又會變成 Features/Orders/Cancel。光看目錄，很難判斷這些選擇在實際開發上差在哪裡。 這篇固定使用同一套 ASP.NET Core API、EF Core 與 PostgreSQL，以「取消訂單」比較三種寫法，再把需求改成「多個入口共用規則」「與付款同時發生」「取消後要發送通知」，觀察程式碼與責任如何變動。比較集中在專案內部的設計、開發與維護成本。
NoSQL 到底解決什麼問題？從 MongoDB、Cassandra、ScyllaDB 看選型與資料可靠性
前言「把一部分查詢搬去 MongoDB，真的會比較快嗎？」「Cassandra、ScyllaDB 為什麼能存那麼多聊天訊息？」「NoSQL 是不是為了效能，接受寫入成功後資料還會消失？」這幾個問題其實連在一起：資料庫用什麼方式組織資料，以及它回覆成功時，到底承諾了什麼。 這篇從實際選型出發，先整理各類資料庫擅長的工作，再深入 MongoDB、Cassandra、ScyllaDB 與 Discord 的遷移案例，最後回到資料遺失、讀寫一致性和 CQRS（命令與查詢職責分離）讀模型。重點是找出哪個工作負載值得換工具，以及換了之後要承擔哪些責任。
