Entity Framework只使用存储过程

Question

我有一个关于在我们的情况下仅使用存储过程与实体框架合理性的问题。

我们计划采用N层架构，包括UI、BusinessLayer（BLL）、DataAccessLayer（DAL）和BusinessObjectDefinitions（BOD）层。BOD层为所有其他层所知，并且从DAL执行查询的结果应在传递到BLL之前转换为对象（在BOD中定义）。

我们将仅对所有CRUD方法使用存储过程。因此，在选择存储过程的情况下，我们将添加函数导入，创建复杂类型，并在执行函数时将复杂类型的值转换为BOD类的类，然后将其传递给BLL。基本上，我们在模型中没有实体，只有复杂类型，这些类型在转换为业务对象后会被转换。

我不确定这是否有意义，因为我认为我们失去了EF提供的很多好处。

还是我完全错了？

- chris vietor

Answer 1

我不同意这里已经存在的两个答案。Petapoco很好，但是我认为EF仍然提供了许多优势。

对于执行读取单个实体或实体列表的简单存储过程，Petapoco工作得很好（甚至可能比EF更好）。但是，一旦你读取了数据并需要开始修改它，我认为这就是EF明显获胜的地方。

要使用petapoco插入/更新数据，您需要手动调用insert/update存储过程，如下所示：

db.Execute("EXEC spName @param1 = 1, @param2 = 2")

当插入/更新存储过程插入超过几个列的行时，手动构建存储过程调用并声明所有参数会很快变得老套。当调用实现乐观并发（即传递原始值作为参数）的更新存储过程时，情况会变得更糟。

您还面临在内联存储过程调用中出现拼写错误的风险，这很可能在运行时才能发现。

现在将其与实体框架进行比较：在EF中，我只需将我的存储过程映射到edmx中的实体即可。由于实体框架工具会通过分析我的存储过程自动生成映射，因此出现拼写错误的风险较小。

实体框架还可以处理乐观并发而无需任何问题。最后，在保存更改时，唯一的步骤就是调用：

entities.SaveChanges()

- actf

Answer 2

如果只使用存储过程，我不会使用EF。个人而言，我会考虑像PetaPoco、Massive或者纯粹的Ado.Net之类的东西。

编辑：

这里有一个PetaPoco消耗SP并输出自定义类型的例子。

http://weblogs.asp.net/jalpeshpvadgama/archive/2011/06/20/petapoco-with-stored-procedures.aspx

- taylonr

Answer 3

我同意，如果你依赖存储过程来处理所有的CRUD方法，那么就没有必要使用EF。

- J.W.

Answer 4

我使用EF将存储过程映射为我们的DAL。通过映射函数，它节省了编写DAL的时间。我们没有经常使用LINQ to SQL，因为我们的DBA不希望直接访问数据表。

- KeyOfJ

---

这种方法对你有用吗？我也面临同样的问题，只是想确保在创建存储过程、从 EF 调用它们等过程中是否需要注意任何特定的情况。如果您有任何建议，将不胜感激！ - Libin M