只有存储过程的实体框架

Question

我有一个关于在我们的场景中只使用存储过程使用实体框架的合理性的问题。我们计划使用UI，BusinessLayer（BLL），DataAccessLayer（DAL）和BusinessObjectDefinitions（BOD）层构建N层架构。所有其他层都知道BOD层，DAL中执行查询的结果在传递到BLL之前应该转换为对象（在BOD中定义）。

我们将只对所有CRUD方法使用存储过程。 因此，在选择存储过程的情况下，我们将添加一个函数import，创建一个复杂类型，并且当我们执行该函数时，我们将复杂类型的值转换为一个BOD类并将其传递给BLL。 基本上，我们在模型中没有实体，只是复杂类型，它们被转换为Business Objects。

我不确定这一切是否合理，因为在我看来，我们损失了很多好处，EF提供。

还是我完全错了？

Answer 1

我不会使用EF，如果我刚刚使用的是存储过程。

就个人而言，我想看看像PetaPoco，大规模甚至只是直Ado.Net

编辑

这里是PetaPoco消耗SP和输出自定义类型的例子

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

Answer 2

我同意，如果你依赖所有CRUD方法的存储过程，那么不需要使用EF。

Answer 3

我不同意这里的两个现有答案。 Petapoco很棒，但我认为EF仍然有很多优点。

Petapoco在执行读取单个实体或实体列表的简单存储过程时效果很好（甚至可能比EF更好）。但是，一旦你阅读了数据并需要开始修改它，我觉得这是EF明确的赢家。

要插入与petapoco你需要使用手动调用插入/更新存储过程/更新的数据：

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

手动构建存储过程调用，并声明所有的参数变老非常快的时候插入/更新存储过程插入行数不止一列。当调用实现乐观并发的更新存储过程（即将原始值作为参数传入）时，情况会更糟糕。

您还可能在内存存储过程调用中犯错误，这很可能在运行时才会被捕获。

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

实体框架也将处理乐观并发，没有任何问题。最后，当需要保存我的更改时，只需拨打以下电话：

entities.SaveChanges() 

Answer 4

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