在Entity Framework中使用带额外参数的存储过程的策略4

Question

我有一种情况，业务需求决定所有数据访问都是通过存储过程完成的。我选择使用实体框架，因为我知道存储过程的支持在4.0中得到了很大的改进，但是，我有一组包含一些额外参数（UserName，ReasonCode等）的过程，它们将用于proc中的附加逻辑。这是一个非常常见的情况，所以我很惊讶，EF让它难以置信地难以实现。

当我看到我的唯一选项解决这个越来越如下：

1. 创建一个查询基础表数据库中的视图，并包含空值额外的列名。
2. 处理SaveChanges事件，或覆盖上下文中的SaveChanges方法并手动处理函数调用。

选项1在我目前的项目中不存在问题，但它是最简单的。

选项2是一个令人难以置信的工作量。 EF的全部重点是让我不必编写易于出错的令人生厌的繁琐数据访问代码。让我们来看看这里所涉及的工程潜在数量：

1. 创建为每个实体需要此信息的函数的进口，并在必要每次修改操作（插入，更新，删除）
2. 创建包含一些常见类型所有这些信息，并通过部分类将其应用于每个实体。
3. 写的每个方法映射功能为每个实体（3 * N）注意，这也涉及到获得原始值的更新和删除
4. 覆盖SaveChanges方法来检查每个实体，看它是否是正确的IFoo接口，检查实体的状态，然后调用该实体类型的适当方法。

我错过了什么？为什么这样一个常见的情况很难执行。

我知道有人可能认为我可以编写一个T4模板来为我生成所有这些代码，但这只是让我回到了这样一个繁琐的样板代码，它没有增加真正的价值。有一个简单的方法可以说：

“哟EF！我打电话给proc！我知道我在做什么，我想在capiche中添加这些额外的值？“

为好奇额外的信息：

• 我使用的是自跟踪实体与WCF模板
• 附加PARAMS不存在任何地方，可以通过实体
挂
• 附加参数始终是相同的
• 存储过程如下，它们不能从其当前合同中修改

任何对此事的帮助或见解都将非常受欢迎！

干杯，
乔希

Answer 1

EF的整点是我 保存不必编写头脑麻木 繁琐的数据访问代码，这将是 容易出错。

正确，它的做法是使用T4变换为您编写样板代码。

我知道有人可能以为我 可以写一个T4模板来生成 所有这些代码对我来说，但只是 把我带回到它是 ，增加了无 真正繁琐的样板代码点值。

......这就是为什么利用T4似乎是解决这个问题的明显方法。您所描述的代码并不比实体框架已经为您生成的代码更繁琐。实际上，您可以更改实体上下文，以便首先由您自己的自定义T4模板生成.edmx.cs文件，而不是通过Visual Studio的内置转换。

我还没有在实体框架中使用存储过程，因此可能有更好的方法来完成你所描述的内容，但是如果它能解决的话我不会太快地折扣T4方法你的问题充分。

Answer 2

有一个在MSDN论坛线程有关此主题：
http://social.msdn.microsoft.com/Forums/en-US/adodotnetentityframework/thread/182c99d0-5fde-4292-b356-4f9a4d86e032/
我遇到了同样的问题，我想我会去恰与CUD程序作为标准功能的进口，而不是使用的SaveChanges（）。