Question

我对在我们的场景中仅使用存储过程的实体框架的合理性提出了疑问。

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

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

我不确定这一切是否有意义，因为在我看来，我们失去了很多好处，EF提供。

还是我完全错了？

Answer 1

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

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

要使用petapoco插入/更新数据，您需要使用以下方法手动调用插入/更新存储过程：

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

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

您还冒着在内联存储过程调用中输入拼写错误的风险，这很可能在运行时才会被捕获。

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

实体框架也将毫无问题地处理乐观并发。最后，当需要保存我的更改时，唯一的步骤是调用：

entities.SaveChanges()

Answer 2

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

就个人而言，我会看看像PetaPoco，Massive甚至是Ado.Net这样的东西

修改

以下是PetaPoco消费SP并输出自定义类型的示例

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

Answer 3

我同意，如果您依赖所有CRUD方法的存储过程，则无需使用EF。

Answer 4

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