.NET 實體框架和存儲過程

Question

我是 EF 的新手，我遇到了一個哲學問題：所有的書籍、視頻、在線課程等 - go 關於直接使用表數據庫 - 即使用直接對應於它們的類。 我創建的 class 如何將表格和所有這些抽象出來。 然后整個書籍或課程展示了我可以對 class 做的所有事情，這些事情又將發生在數據庫表中——CRUD 操作等。

我在想——我們從不直接使用表格，這是有原因的。 這是一個壞主意 - 讓我們手動完成或讓框架為我們處理它。 我們總是使用存儲過程，這是應該完成的方式（它們通常返回從一堆表中連接的 SELECT，這樣我們利用關系 model 並將其封裝。我們授予執行存儲過程的權限，而不是直接執行, 完全訪問表格等...)

但是所有的 EF 材料都是 99% 的 OR 映射，即代碼到物理表，然后快速提及它可以使用存儲過程來完成。

那么……這就是 EF 哲學背后的思想嗎？ 我做對了嗎...... MS 的人在想什么？

謝謝

Answer 1

我認為這個問題真的是 ORM vs non-ORM。 您提到存儲過程是執行此操作的“正確”方式，我認為十年前的大多數人都會同意您的看法。 但是，正如您所說，ORM 只是 SQL （或任何查詢語言）之上的一種更具表現力、更易於閱讀的抽象。

關於過度許可有一些話要說，ORM 肯定需要對數據庫更多的權限，而不僅僅是在存儲過程上execute 。 安全性的權衡（如果它真的不能在另一個級別上控制）是開發人員的速度、可測試性和可維護性。 這並不是說查詢語言不能成為任何這些東西，但這是抽象的主要目標。

我曾在硬幣兩面的商店工作過。 根據我的經驗，使用 ORM 的商店似乎也有更高的速度。 是否直接相關，我不能說。

Answer 2

還有更多：EF 不綁定也不限於 SQL 服務器。 它是數據層的抽象，與數據庫方法相比有一些好處。

順便說一句，您可以在 EF 中調用存儲過程，但這里還有其他一些好處：

• 抽象數據訪問
• 在代碼中明確定義數據表、視圖等。 這有助於防止映射錯誤。
• 代碼優先具有非常明確的遷移策略
• 和; 它允許您切換實際的數據庫類型。 這在編寫測試時很有幫助。
• 最后：它可以節省大量時間，並且對於了解 C# 的人來說，學習曲線並不陡峭

Answer 3

首先請注意，您還可以擁有表示視圖的類，並且您還可以使用 EF 執行存儲過程。

此外，當您進行聯接或使用 category.Products 等導航屬性時，請注意，EF 正在創建並執行相同的聯接。

所以 EF 只是一種讓數據庫更容易使用的方法，但它並沒有取代我們擁有的功能。 我想要一些可以與存儲過程一起使用的東西。 這是我使用存儲過程的真實代碼中的一個示例：

List<Flower> flowers =  = context.Flowers.FromSqlRaw("GetFlowers {0}, {1}, {2}", domain, country, currency).ToList();