实体框架和字符串键之间的关联答案

【问题标题】：Entity Framework and associations between string keys实体框架和字符串键之间的关联
【发布时间】：2010-10-17 20:06:00
【问题描述】：

我是实体框架的新手，而我是那个数学的 ORM。在我参与的项目中，我们有一个遗留数据库，其所有键都是字符串，不区分大小写。

我们正在转换为 MSSQL 并希望使用 EF 作为 ORM，但是遇到了问题。

这里有一个例子来说明我们的问题：

TableA 有一个主字符串键， TableB 引用了这个主键。

在 LINQ 中，我们编写如下代码：


var result = from t in context.TableB select t.TableA;
foreach( var r in result )
    Console.WriteLine( r.someFieldInTableA );

如果 TableA 包含读取“A”的主键，并且 TableB 包含两个引用 TableA 但在引用字段中具有不同大小写的行，“a”和“A”。

在我们的项目中，我们希望两行都在结果中结束，但只有一行匹配的案例将在那里结束。

使用 SQL Profiler，我注意到两行都被选中。

有没有办法告诉实体框架键不区分大小写？

编辑：
我们现在已经使用 NHibernate 对此进行了测试，并得出结论 NHibernate 可以使用不区分大小写的键。所以 NHibernate 对我们来说可能是一个更好的选择。
但是我仍然有兴趣了解是否有任何方法可以改变实体框架的行为。

感谢您的回答！

问题是如果我们现在将该约束添加到数据库中，遗留应用程序可能会因为它的构建方式而停止工作。如果可能的话，对我们来说最好的办法是改变 EF 的行为。我猜这是不可能的，但我正在试一试。

问候，
弗雷德里克

编辑：我之所以添加对自己问题的答案是因为我在注册用户之前添加了这个问题，而当我注册了我的帐户时，我无法添加 cmets 或编辑我的帖子。现在帐户已合并。

【问题讨论】：

【解决方案1】：

我认为您需要在 SQL Server 中更改架构，而不是在 EF 中。这篇关于如何使列区分大小写的帖子的答案看起来可以解决问题：T-SQL: How do I create a unique key that is case sensitive?

【讨论】：

【解决方案2】：

我知道这不是一个完美的解决方案，但在 LINQ 中为什么不自己加入。 EF 不起作用，因为 .Designer.cs 文件在执行连接时返回 objA.Equals(objB)。 .Equals 区分大小写。

var result = from t1 in context.TableB join t2 in context.TableA on t1.someFieldInTableB.ToUpper() 等于 t2.someFieldInTableA.ToUpper();

我知道有点骇人听闻，但 LINQ to Entities 仍处于起步阶段，并且设计的对象类是出于特定原因而设计的，无法处理此类设计中的异常情况。

另一种选择是您可以使用 T4 模板创建自己的代码生成器。由于一切都是公共部分类，您可以创建一个导航属性，该属性实际上执行您正在寻找的不区分大小写的比较。

不过，要如实回答您的问题，没有“开箱即用”的方式让 EF 使用不区分大小写的搜索进行导航。

【讨论】：

【解决方案3】：

我想出了一个解决方法，在上下文从数据库中检索行后，在内存中“缝合”基于字符串的关联（提示：使用上下文。[EntityTypeCollection]。本地属性。你可以在https://stackoverflow.com/a/12557796/62278看到我的回答

【讨论】：

【解决方案4】：

我知道这不是一个完美的解决方案，但在 LINQ 中为什么不自己加入。英孚不起作用，因为 .Designer.cs 文件在执行 >> 连接时返回 objA.Equals(objB)。 .Equals 区分大小写。

好吧，如果你重写 Equals 方法就不会

在 EF 中生成的域类是部分的，不是吗？因此，用您自己的实现替换这些类的默认 Equals 实现相当容易（这当然会使其不区分大小写）

顺便说一句：一种技术可以追溯到 .NET 1.0

由于所有这些 .NET 3.5/4.0、Linq 和 Lambda 暴力，人们往往会忘记基础知识

【讨论】：

【解决方案5】：

作为实体框架的替代方案，您可以使用 LINQ to SQL，它适用于涉及区分大小写的排序规则的关系。虽然这个 ORM 不能提供 EF 或 NHibernate 的所有灵活性，但在许多情况下它就足够了。

【讨论】：