您将如何在典型的业务层/数据访问层/存储过程中使用EF？

Question

每当我观看有关实体框架的演示时，演示器只需设置一些表并使用自动创建的代码存根执行插入，更新和删除，但从不显示任何存储过程的使用。在我看来，这是从客户端执行SQL。

根据我的经验，这不是特别好的做法，所以我假设我对实体框架的理解是错误的。

同样，WCF RIA Services演示使用EF，演示总是相同的。任何人都可以了解如何在典型的业务层/数据访问层/存储过程中使用EF。

我觉得我很困惑，不应该!!？

Answer 1

从客户端执行SQL没有任何问题。当使用像EF这样的东西时，它可能导致的大多数（如果不是全部）问题实际上都不存在。例如：

1. 客户端生成的SQL可能会导致运行时语法错误。这不太可能，因为您的查询的描述主要在编译时检查（假设生成器本身不生成无效的SQL，这也不太可能）
2. 客户端生成的SQL可能效率低下。具有查询缓存的现代数据库软件不是这样。 EF以与查询缓存兼容的方式工作，即它始终如一地生成相同的SQL（只要您始终使用相同的代码）并使用参数来处理不同的数据。
3. 客户端生成的SQL可能不安全（SQL注入和诸如此类）。这全部由生成器处理，生成器使用值的参数，不会将用户输入插入查询本身。

Answer 2

回到旧的客户端/服务器时代，过去被认为是使用存储过程执行所有数据库更新的良好做法。

但现在，让O / RM生成SQL并直接针对DB运行是完全可以接受的。

Answer 3

  

永远不会显示任何存储过程的使用

观看此视频：Using Your Own Stored Procedures to Insert, Update and Delete Entities in Entity Framework。

请注意，该主题还有很多其他视频值得关注！

Answer 4

好吧，为什么在存储过程中执行sql是一个好主意的部分原因是它给你一个抽象级别 - 当db变化不可避免地发生时，你在一个地方（proc）进行更改而不是十几个地方（你调用客户端sql的所有地方）。实体框架通过数据模型提供了这一抽象层，你也有同样的优势。

还有一些其他原因导致您可能希望查看过程，例如安全粒度（仅允许某些用户执行权限），以及一些轻微的性能差异。最终，你必须自己决定什么是正确的权衡。 EF试图大幅减少开发人员创建数据层所花费的时间，并进行了上述权衡。

Answer 5

传说是Scott Hanselman曾经说过“除非有人拖动数据网格，否则这不是真正的演示”（第478页Silverlight 4 In Action，Pete Brown）

你必须记住演示，都是关于销售软件，而不是关于沟通最佳实践。因此，您对演示的观察是绝对正确的，它们涵盖了基础知识，并留给观察者填写空白。

关于存储过程的评论，以及有关生成器的问题的各种答案。发电机很好，而且越来越好。 Howerver在某些情况下会产生完全无法使用的查询。 （请参阅我的问题here和discussed on the ADO.NET team blog）

因此，有时手工制作的查询是您唯一的追索方式（通过存储过程，表值函数，视图等）