覆盖EF的默认插入/更新/删除查询是否有好处

Question

问题确实如此。

EF建模器工具允许我们将插入/更新/删除功能映射到一个sproc，覆盖它们有什么好处吗？

如果它需要一些自定义验证，那么显然是的，但是如果我对现在的情况感到满意，是否值得为它们创建sproc？

我不记得如何查看它正在执行的SQL以找出确切的查询，但我认为它与标准的插入/更新/删除查询非常相似。

Answer 1

是。覆盖它们是有好处的。

发生更新或删除时，并非所有人都实际更新或删除一行数据。

在某些情况下，删除记录实际上只是意味着将EffictiveUntil日期设置为现有记录并将记录保留在数据库中以用于历史目的。

同样可以进行更新。当前行不是更新现有行，而是获取EffectiveUntil日期集，并使用具有null EffectiveUntil日期（或类似机制）的新数据插入全新行。

通过向Entity Framework提供插入/更新/删除逻辑，您可以准确指定这些操作对数据库的意义，而不是它们在RDBMS范围内的含义。

关于第二个问题（我显然最初错过了），如果你对当前正在生成的内容感到满意，那么不值得创建它们。您只需要记住在更改表结构时必须记住更新存储过程的额外麻烦。

Answer 2

我可以想到一些可能有用的案例：

• 您正在使用遗留数据库，该数据库无法准确映射到您的EF模型。
• 您需要在插入/更新/删除时执行额外的查询，但您没有数据库触发器的权限。
• 要从中抽象出来的数据库中的软删除。因此，定期删除实际上会执行软删除。

不太确定这些选项有多可行，因为我个人更像是NHibernate。这些是理论选择。

至于查看已执行的查询，有几种可能性。您可以将分析器附加到SQL Server实例，并查看执行的原始查询。还有Entity Framework Profiler（由Ayende / Oren Eini提供），它不是免费的，但它确实使查询和调试更容易。