如何在 CLR 存储过程中使用实体框架？
我期待将所有逻辑（作为操作 Entity Framework 4 对象实现）移至服务器端。它看起来会很简单（由于应用程序结构）并且有益（因为我只有一台旧笔记本电脑作为客户端和一台运行 SQL Server 2008 的强大服务器，并且为逻辑构建单独的服务只会引入更多延迟如果与在数据库内执行相比）。
那么如何在 CLR 存储过程中正确使用实体框架并使其使用主机服务器提供的 SqlContext？
突然我在网上找不到任何例子。看起来很奇怪，还没有人吃过这个。这是否意味着这项任务很荒谬，我绝对不应该这样做？使用 T-SQL 直接访问表而不是 EF 类并不是很方便，因为我的模型大量使用继承，并且具有由许多非常简单的表组成的非常复杂的每类型表结构。
I am looking forward to move all the logic (which is implemented as manipulating Entity Framework 4 objects) to a server side. It looks going to be simple (thanks to the application structure) and beneficial (as all I have is one oldy laptop as a client and one tough server which runs SQL Server 2008, and building a separate service for the logic can just introduce more latency if compared to doing it inside the database).
So how do I correctly use Entities Framework inside a CLR stored procedure and make it using a host-server-provided SqlContext?
Suddenly I couldn't find any examples in the Web. Looks stragne that none has yet dine this. Does it mean that the task is ridiculous and I definitely should not do that? It won't be very convenient to use T-SQL and access tables directly instead of EF classes because my model makes heavy use of inheritance and has a very complex table-per-type structure of lots of very simple tables.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
似乎使用 SQL Server 2008 R2 或更高版本就可以，它使用 .NET 版本。 4.0。请参阅
我对 SQL Server 2010 Developer Eeition: 运行以下命令
并得到以下输出：
Seems that with SQL Server 2008 R2 or greater you can, it uses .NET ver. 4.0. See this blog.
I run the following command against my SQL Server 2010 Developer Eeition:
and got the following output:
不，你不能。 Visual Studio 甚至不允许您添加文件或项目类型。 （这太糟糕了，我也想这样做来处理一些非常复杂的逻辑。）
No, you can't. Visual Studio wouldn't even let you add the file or project type. (That's too bad, I wanted to do that also to process some really complex logic.)
我们中的一些人并不热衷于在两个或多个地方维护数据库模式元数据。 EF 很适合做到这一点，但如果想要利用 SQL-CLR 的性能优势，则必须在其上下文中定义架构。目前这意味着 SQL-CLR 程序集中的自定义元数据代码生成 DDL 来定义数据库并将其导入 EF。
Some of us are not that keen to maintain database schema metadata in two or more places. EF is great to do this, but if one wants to employ the performance benefits of SQL-CLR the schema has to be defined in its context. Which at the moment means a custom metadata codes in SQL-CLR assembly that generates DDL to define a database and import it to EF.
你不能——至少现在不能。 SQL Server 2005 到 2008 R2 中包含的 CLR 是 .NET 2.0 CLR，而 Entity Framework 4 需要 .NET 4 框架。
因此，目前，当在 SQL-CLR 方法中执行操作时，您只能使用直接的 ADO.NET 2.0。
更大的问题仍然存在：到底为什么要在 SQL-CLR 函数中使用 EF4？这些旨在存储过程、用户定义的函数、用户定义的聚合 - 但肯定不是成熟的数据库应用程序，真的......
You cannot - at least not at this time. The CLR contained in SQL Server 2005 through 2008 R2 is the .NET 2.0 CLR - and Entity Framework 4 requires the .NET 4 framework.
So for now, when doing stuff inside a SQL-CLR method, you're limited to straight ADO.NET 2.0 only.
The bigger question then remains: why on earth would you want to use EF4 inside a SQL-CLR function? Those are intended to be stored proc, user-defined functions, user-defined aggregates - but certainly not full-blown database apps, really...