Microsoft 经常提供一些方法，使开发简单而琐碎的东西变得容易。
在 EFxx 中有一些我不喜欢的东西。首先，为了进行更新，您需要先加载记录，因此操作变成了一个两步过程，您可能只想更新一个布尔值。
其次，我喜欢存储过程，因为我可以在同一个连接调用中运行 10 个不同的东西，如果我使用 EFxx，我将不得不运行 10 个单独的 DB 调用（或者如果涉及更新，则更多）。
我对 MVC EF 专家的关注和问题是……使用存储过程是个坏主意吗？我仍然认为 EFxx 只是 Microsoft 为我们提供更快开发简单程序的另一种方式，但实际上它并不是真正推荐的方式。
任何提示和技巧都将不胜感激，特别是关于“在 EFxx 上运行更新的最佳方法是什么”和“存储过程对 EFxx 不利”的概念。
你陷入了一个逻辑谬误。仅仅因为 EF 旨在以某种方式工作并不意味着您不应该以不同的方式进行操作。仅仅因为 EF 可能不适合以某种方式做某件事并不意味着 EF 很糟糕或不应该用于任何事情。这是全有或全无的论点。如果它不能完美地完成所有事情，那么它就是无用的......这不是真的。
EF 是一个对象关系映射工具。仅当您想将数据作为对象处理时才使用它。如果您想将数据作为关系集（又名 SQL）处理，则不会使用它。
您也不会坚持使用 EF 或什么都不用。您可以使用 EF 进行查询，并使用存储的过程进行更新。或者反过来。这是关于使用最适合给定情况的工具。
不，EF 不仅仅适用于“简单”或“琐碎”的事情。但是，将它用于更复杂的场景通常需要更深入地了解 EF 的工作原理，以便您了解它在幕后所做的事情。
在 EF 中使用存储过程就像说MyContext.Database.ExecuteSqlCommand()or一样简单MyContext.Database.SqlQuery()。这是最基本的方法，它提供了基本的对象到 sproc 映射，但它不支持更复杂的 ORM 功能，如缓存、更改跟踪等。
EF6 将更全面地支持存储过程以支持查询、更新和删除，从而支持更多功能集。
EF 不是灵丹妙药。它需要权衡取舍，您需要决定在您要使用它的情况下它是否适合您。
仅供参考，在更新对象之前需要获取对象是绝对错误的，尽管这只是处理它的最简单方法。EF 还实现了一个工作单元模式，因此如果您进行 10 次插入，它不会进行 10 次往返，它会将它们全部作为单个准备好的语句发送。
就像你可以编写糟糕的 SQL 一样，你也可以编写糟糕的 EF 查询。仅仅因为你擅长 SQL 而不擅长 EF 并不意味着 EF 很烂。这意味着，你还不是这方面的专家。
所以对于你的问题，不。从来没有人说过使用 Sprocs 是一个坏主意。问题是，在许多情况下，存储过程是多余的。它们还将您的逻辑人为地分离为两个不同的子系统。用 C# 编写查询意味着您完全用一种语言编写业务逻辑，这对维护有很多好处。有些环境需要使用 sproc，有些则不需要。
这个问题已经被问过很多次了。喜欢这个。
两者总是有利有弊。这只是对你来说重要的事情。您是否只需要简单的 CRUD 操作（一次一个）？我可能会使用 ORM。你做批量数据库操作吗？使用 SP。你需要做快速开发吗？使用 ORM。您是否需要灵活性以便完全控制 SQL？使用 SP。
另外，请注意，您可以减少您在 EF 中的上下文执行的 DB 行程次数。您可以尝试阅读有关不同类型的 EF 加载的更多信息。此外，在 EF 中可以调用 SP。使用 SP 读取数据并使用 SP添加/更新。