EF 支援從存儲過程生成實體方法：為何說不？
存儲過程屬技術架構（資料庫），實體方法屬領域模型（業務行為）。兩者混淆是典型反模式。
專家觀點佐證
「架構師指出使用 EF 的反模式：機械地從資料庫結構生成領域模型（資料庫驅動）。指南核心應為領域驅動開發，重點在於如何在關係模型之上建構概念模型。」—— Andrey Yemelyanov
證實：只能從領域模型映射到資料模型，反向不可取。
存儲過程的正確定位
- 處理資料，非物件。業務層不應將領域對象交給資料庫處理。
- 優勢：減少網路往返、服務端批量運算（如統計報表）。
- 適用：與業務無關、高頻查詢、大量資料運算。
- 不適用：業務邏輯封裝，會導致領域模型貧血、混亂、難應對變更。
技術選型建議
- 依需求決定，非銀彈。
- 原則不推薦用於業務邏輯。
- 效率確需時酌情使用，注意資料庫綁定風險（SQL Server/Oracle 語法不通用，部分資料庫不支援）。
期望
希望 EF 未來移除「實體方法映射到存儲過程」功能，行為屬領域，不應下沉至基礎設施層。
