小小大大學

  內容 想把 C# 類別正確對應到資料庫表（Code-First），你一定會遇到 Data Annotations 與 Fluent API 。這兩者其實都是在做「模型組態」（Model Configuration）：也就是 告訴 EF Core 你的類別如何對映到資料表 。差別在於「寫法位置」與「可表達能力」。 TL;DR（先給結論） Data Annotations ：直接在類別/屬性貼 Attribute（如 [Key] , [Required] , [MaxLength] ）。 上手快、就地可讀 ，但表達力有限。 Fluent API ：在 OnModelCreating 或 IEntityTypeConfiguration<T> 裡用鏈式語法設定。 最完整、可抽離、可維護 ，適合中大型專案。 衝突優先序： 慣例 < Data Annotations < Fluent A...

  摘要（Meta Description） 在 .NET EF Core 對 Oracle 查詢時，若遭遇 ORA-00600 [kpp_concatq:2] ，多半是查詢優化器在字串型別轉換或重寫（Query Transformation）時踩到版本 Bug。本文以實戰日誌形式，示範如何用 FromSqlRaw + 參數型別/長度對齊 + CAST + Hint 立即止血，並處理 EF Core 另一個常見錯誤：「 CultureInfo 常值被傳進 ToString 造成可能記憶體外洩 」。附可直接套用的程式碼。 目錄 錯誤現象 根因分析 三步驟「立即止血」 安全重構：可直接貼用的程式碼 進階避雷：CTE/MATERIALIZE 與 View 包裝 EF Core ToString / CultureInfo 錯誤的正確處理 版本與長期解法（根治） 效能與穩定性小技巧 檢查清單（Checklist） FAQ 結語 錯誤現象 常見堆疊片段如下（節錄）： Oracle .ManagedDataAccess .Client .OracleException ( 0 x80004005): ORA-00600 : 內部錯誤代碼, 引數: [kpp_concatq:2] , [4] , [3] ...

  摘要（TL;DR） 想把 PageThree.vue 改成 PageOne.vue ，又要把程式裡所有寫到 PageThree 的地方同步改掉？ 最穩做法是： 先開啟 VS Code 的「檔案移動自動更新 import」→ 重新命名檔案 → 全域搜尋 PageThree 用正則 \bPageThree\b 取代為 PageOne → 檢查 router 與元件 name 。文末也提供 macOS/Linux 與 Windows PowerShell 的一鍵命令列。 為什麼「改檔名」會影響整個專案？ 在 Vue 專案裡，元件通常會被： 其他檔案 import （匯入） router/index.ts 內註冊為路由 component / name 模板中以 <PageThree /> 使用 以程式變數或函式參數命名（例如 const PageThree = ... ） 只改檔名，不處理以上地方，就會出現「找不到模組」或「組件名稱不一致」的錯誤。 步驟一：開啟 VS Code 的自動更新 Import 在 VS Code： 設定 → 搜尋 Update Imports On File Move ，將 javascript.updateImportsOnFileMove.enabled 設為 always typescript.updateImportsOnFileMove.enabled 設為 always 這樣你在 重新命名或搬移檔案 時，VS Code 會自動替你更新各處的 import 路徑。 建議外掛 ：啟用 Vue - Official (Volar) ，更聰明地處理 Vue 檔與類型提示。 步驟二：重新命名檔案（關鍵）...

 新手常問：「程式能跑就好，為什麼還要『重整（Refactor）』？」 答案：因為專案會長大、會交接、會改需求——今天看得懂，三個月後也要看得懂。這篇用 實際專案片段 （Vue 3 前端、ASP.NET Core API、EF Core 實體與資料處理服務）一步一步把「可讀性」與「維護性」講清楚，讓 不懂程式的人也能看懂工程師在做什麼 。 #1 為什麼「可讀性」與「維護性」這麼重要？ 可讀性 ：像寫給未來的自己／同事看的說明書。越好讀，改錯率越低。 維護性 ：遇到新需求、異常或交接時，能快速定位與修改。 直接影響成本 ：好讀好...