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

微软经常提供方法，使开发简单而琐碎的东西变得容易

在EFxx中有一些我不喜欢的东西。 首先也是最重要的一点是，为了进行更新，您需要首先加载记录，因此操作将变成一个两步过程，您可能只需要更新一个布尔值

其次，我喜欢存储过程，因为我可以在同一个连接调用中运行10个不同的东西，如果我使用EFxx，我必须运行10个单独的DB调用（如果涉及更新，则需要运行更多）

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

---

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

这一问题已被多次询问和回答。像

两者都有利弊。这只是一个什么对你重要的问题。您是否只需要简单的CRUD操作（一次一个）？我可能会使用ORMs。你做批量数据库操作吗？使用SPs。你需要快速开发吗？使用ORMs。您是否需要灵活性，以便完全控制SQL？使用SP

---

另外，请注意，您可以减少EF中上下文的DB trips次数。你可以试着阅读更多关于不同类型的书籍。此外，在EF.&中也可以调用SPs

你陷入了逻辑谬误。仅仅因为EF被设计成一种特定的工作方式并不意味着你不应该用不同的方式来做。仅仅因为EF不适合以某种方式做某件事并不意味着EF很差劲或者不应该用于任何事情。这是全有或全无的论点。如果它不能完美地完成每一件事，那它就是无用的。。但事实并非如此

EF是一个对象关系映射工具。仅当您希望将数据作为对象使用时才使用它。如果希望将数据作为关系集（也称为SQL）使用，则不会使用它

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

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

在EF中使用存储过程非常简单，只需说

MyContext.Database.ExecuteSqlCommand（）

或

MyContext.Database.SqlQuery（）

。这是最基本的方法，它提供了基本的对象到存储过程的映射，但不支持更复杂的ORM功能，如缓存、更改跟踪等

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

EF不是一颗神奇的子弹。它有权衡，你需要决定它是否适合你使用它的环境

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

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

---

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

您不需要先加载。您只需将状态设置为

Modified

。为什么只限于一种方法？我喜欢我的LINQ2SQL（想想“mini-EF”）——我也喜欢SQL Server的功能。虽然LINQ2SQL（或者任何ORM）可以使许多任务变得简单（并且做得足够好），但它并不总是能把每件事都做到最好。我使用SPs、触发器、层次ID、视图等。只要在适当和/或有可测量优势的地方使用它们即可。如果在DAL后面使用EF（或任何ORM），那么任何一个GOTCHA（总是有一些！）都更容易处理。我同意你的观点…但我不明白的是如何使用DbContext使用存储过程（见此），你确定吗“，因此，如果您要进行10次插入，它不会进行10次往返，它会将它们作为一个单独的准备语句发送。”，我的印象是EF不支持命令批处理？所以您的意思是混合使用这两种技术是有意义的。对吗？