C# 我应该从SQL CLR函数中使用EF6吗

我的任务是研究一些复杂的计算代码（用C#）并将其转移到SQLServer2012上的CLR函数中。计算的复杂性意味着将其作为经典的SQL SP或UDF编写是不可行的，因此使用CLR的想法是存在的，并且已经过测试

我的问题是，计算使用的数据层使用EF6。显然，我将为CLR函数提取尽可能小的一部分现有代码，但我仍然必须满足所有依赖项

我的问题不是我怎样才能做到这一点（后面会提到：）]而是我应该做这件事吗？不知何故，将整个EF填充到我将要访问的数据库中以执行计算是错误的——它感觉非常臃肿

意见、建议、想法

谢谢

除非在应用层和这个SQLCLR函数之间保持代码库同步有非常迫切和特殊的需要，否则我会说：

不，这样做似乎没有什么好处。您应该只需要几个数据点，这些数据点非常容易通过使用

Context Connection=true的简单
SqlConnection
获取

而且，考虑到性能是一个问题（无论如何都应该如此，但仍然如此），因此我们要从这个SQLCLR路径开始，添加一层又一层的代码来实现实体框架的易用性抽象层似乎会适得其反

另外，为什么要从函数中获取数据，而不是将其传递到函数中？是否有传入的值需要根据其特定值进行额外查找？通过将标量函数构造为确定性函数，您将获得相当多的性能：

在
SqlFunction
属性中标记为
IsDeterministic=true
的标量SQLCLR函数将其输出缓存并映射到输入参数，以便可以查找（在同一查询中的其他行的上下文中）并重新使用，而不是再次运行该函数，以及

并行计划中允许在
SqlFunction
属性中标记为
IsDeterministic=true
且未标记为
DataAccess=DataAccessKind.Read
的标量SQLCLR函数。如果
IsDeterministic
未标记为
true
或
DataAccess
（甚至
SystemDataAccess
）标记为
Read
，则它们将像常规的T-SQL函数一样工作，因为它们将阻止使用它们的任何查询获得并行执行计划

需要的是，计算功能既可以从SQL服务内部（其他SP、reporting Services、其他当前未重新开发的系统）访问，也可以从传统的外部系统访问。因此，需要将代码封装在两种环境均可访问的一个位置。代码非常复杂，使用多个查找和数据传递—本质上是财务的。试图将C#转换成SQL将是一场噩梦，除此之外，我们还有一个目前正在工作的机制。@Mike:嘿。我想说，这是关键信息，应该在问题：-）。另外，“将代码封装在两种环境都可以访问的一个位置”是什么意思？SQLCLR代码托管在SQL Server中，无法从外部访问，也不会访问远程对象（尽管它可以访问在同一系统上注册的COM组件）。如果在数据库中完成计算时速度最快，那么中心位置可能应该是SQLCLR函数；-）@迈克，我回复的时候还没有看到你对评论的更新。您将如何使用这个SQLCLR函数？在SELECT或WHERE子句中（即，它将在多行数据集的每行中运行）？或者作为为该批运行一次的更大一批SQL语句的一部分？我并不是说，如果它必须进行数据访问，那么它将一文不值，只是说不这样做有很大的好处。但如果这不可能，那好吧。总的来说，我同意通过SQLCLR做一些复杂的事情（因此；-），只是试图引导你达到最好的结果：）。我感谢你的评论，伙计，不用担心。我们的想法是，最好有一个dll（忽略依赖性问题），其中包含可以直接从.net组件调用的计算，但我们也可以将其嵌入CLR函数中，以允许从SQL Server中调用它-基本上我们只需要为其维护一个代码库。为了（我认为）清晰起见，我稍微简化了这个场景，它实际上是一组函数，其中一些函数返回单个值，另一些函数返回数据集。@Mike，我不认为它能很好地解决这个问题。SQLCLR是一个非常受限的CLR主机环境。我渴望有一个单一的代码库，真的，但我在这里是现实的。鉴于
SqlTypes
与常规.Net类型略有不同，您至少需要SQLCLR的包装器方法来调用现有的通用方法。但这取决于它们在做什么，可能需要对公共代码库进行更改。不能使用类级别的静态变量。您可能需要将所有EF DLL导入SQL Server。这是一个不同的环境，代码应该与之匹配。