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

Question

我有一种情况，业务需求要求所有数据访问都是通过存储过程完成的。我选择使用 Entity Framework 是因为我知道存储过程支持在 4.0 中得到了极大的改进

但是，我有一组程序，其中包括一些额外的参数(用户名、原因代码等)，这些参数将用于 proc 中的其他逻辑。这是一个非常常见的场景，所以我很惊讶 EF 让实现这一目标变得异常困难。

在我看来，解决此问题的唯一选择如下:

在数据库中创建一个查询基础表的 View ，并包含带有空值的额外列名。

处理 SaveChanges 事件，或在上下文中覆盖 SaveChanges 方法并手动处理那里的函数调用。

选项 1 在我当前的项目中是不可能的，尽管这将是最简单的。

选项 2 是一项令人难以置信的工作量。 EF 的全部意义在于让我不必编写容易出错的令人费解的乏味数据访问代码。让我们看看这里可能涉及的工作量:

为需要此信息的每个实体以及每个必要的修改操作(插入、更新、删除)创建一个函数导入

创建一些包含所有信息的通用类型，并通过部分类将其应用于每个实体。

为每个实体的每个方法编写一个映射函数 (3*N) 请注意，这还涉及获取更新和删除的原始值

重写 SaveChanges 方法以检查每个 Entity 以查看它是否是正确的 IFoo 接口(interface)，检查实体的状态，然后为该实体类型调用适当的方法。

我错过了什么吗？？？为什么如此常见的场景如此难以执行。

我知道有人可能认为我可以编写一个 T4 模板来为我生成所有这些代码，但这只是让我回到了一点，即它是乏味的样板代码，没有增加任何实际值(value)。必须有一种更简单的方法可以说:

“哟 EF!我正在调用 proc!我知道我在做什么，我想在 capiche 中添加这些额外的值？”

好奇的额外信息:

我正在使用带有 WCF 的自我跟踪实体模板

实体

可以链接到的任何地方都不存在附加参数。

附加参数始终相同

存储过程保持原样，无法从当前合约中修改

任何对此事的帮助或见解都将受到欢迎!

干杯，
乔什

Answer 1

The whole point of EF is to save me from having to write mind-numbingly tedious data access code that will be error prone.

是的，它这样做的方式是使用 T4 转换为您编写样板代码。

I know someone is probably thinking I could write a T4 template to generate all this code for me, but that just brings me back to the point that it is tedious boilerplate code that adds no real value.

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

我还没有在 Entity Framework 中使用存储过程，所以可能有更好的方法来做你所描述的事情，但如果 T4 方法可以充分解决你的问题，我不会太快打折。