c# - 使用存储过程是个坏主意吗？

Question

Microsoft 经常提供一些方法来简化简单琐碎的事情的开发。

我不喜欢 EFxx 中的某些内容。 首先，为了进行更新，您需要先加载记录，因此操作变成了一个两步过程，您可能只想更新一个 bool 值。

其次，我喜欢存储过程，因为我可以在同一个连接调用中运行 10 个不同的东西，如果我使用 EFxx，我将不得不运行 10 个单独的数据库调用(如果涉及更新，则更多)。

我对 MVC EF 大师的关注和问题是...... 使用存储过程是个坏主意吗？我仍然认为 EFxx 只是 Microsoft 为我们提供的另一种更快地开发简单程序的方式，但实际上这并不是真正推荐的方式。

任何提示和技巧将不胜感激，特别是关于“在 EFxx 上运行更新的最佳方式是什么”和“存储过程是否对 EFxx 不利”的概念。

Answer 1

您正在陷入逻辑谬误。仅仅因为 EF 被设计为以某种方式工作并不意味着您不应该以不同的方式来做。仅仅因为 EF 可能不适合以某种方式做某事并不意味着 EF 很糟糕或不应该用于任何事情。这是全有或全无的论点。如果它不能完美地完成所有事情，那么它就毫无用处……而事实并非如此。

EF 是一种对象关系映射工具。只有当您希望将数据作为对象来使用时，您才会使用它。如果您想将数据作为关系集(又名 SQL)来处理，则不会使用它。

您也不会受限于使用 EF 或什么都不用。您可以使用 EF 进行查询，并使用存储过程进行更新。或者反过来。这是关于使用最适合给定情况的工具。

不，EF 不仅仅适用于“简单”或“微不足道”的事情。但是，将它用于更复杂的场景通常需要更深入地了解 EF 的工作原理，以便您知道它在幕后做了什么。

在 EF 中使用存储过程就像说 MyContext.Database.ExecuteSqlCommand() 或 MyContext.Database.SqlQuery() 一样简单。这是最基本的方法，它提供基本的对象到存储过程的映射，但它不支持更复杂的 ORM 功能，如缓存、更改跟踪等。

EF6 将更全面地支持存储过程以支持查询、更新和删除，从而支持更多功能集。

EF 不是 Elixir 。它需要权衡取舍，您需要根据您要使用它的情况来决定它是否适合您。

仅供引用，您认为需要在更新对象之前获取对象是完全错误的，尽管这只是处理它的最简单方法。 EF 还实现工作单元模式，因此如果您执行 10 次插入，它不会进行 10 次往返，而是将它们全部作为一个准备好的语句发送。

就像您可以编写糟糕的 SQL 一样，您也可以编写糟糕的 EF 查询。仅仅因为您擅长 SQL 而不擅长 EF 并不意味着 EF 很烂。这意味着，您还不是这方面的专家。

所以对于你的问题，不。没有人说过使用 Sprocs 是个坏主意。问题是，在许多情况下，sproc 是多余的。它们还会人为地将您的逻辑分成两个不同的子系统。用 C# 编写查询意味着您完全用一种语言编写业务逻辑，这有很多维护好处。有些环境需要使用存储过程，有些则不需要。