外键上的实体框架nvarchar案例敏感性

Question

我有相当简单的表格结构如下,发出的声音对我来说很奇怪.虽然我选择了解决它,但想听听专家的意见.

我有两张桌子

Users
UserName nvarchar(250) Primary Key
FirstName nvarchar(50)
LastName  nvarchar(50)

Registrations
Id BigInt PrimaryKey
User nvarchar(250) - Foreign to Users Table
Date - DateTime

Data I have is as follows.
Users
UserName FirstName LastName
a        Small     A 
b        Small     B

Registrations
Id       User      Date
1        A         1/1/12
2        B         1/1/12

请注意这里的用户案例是它在SQL中有效,它接受.

现在是有趣的部分.我生成了EDMX,.Net 4.0,现在我执行了这段代码.

 using (EFTestEntities context = new EFTestEntities())
            {
                var item = context.Registrations.Where(id => id.Id == 1).FirstOrDefault();
                Response.Write(item.User1.LastName);
            }

它只是打破空指针异常User1抛出Null,当我将Registrations表中的UserName列的值更改为a而不是A时它可以工作.

这个链接谈论有点相似

这链接另一个类似的问题

请分享您的答案为什么会出现这种情况,我的数据库的排序是不区分大小写的.你遇到过类似的情况吗

Answer 1

这里的问题是你的数据库不区分大小写,但CLR(.NET)不是,而且与数据库不同,它不能全局切换到不区分大小写的模式 - 你必须按比较进行.

当你调用item.User1.LastNameEF将触发延迟加载-附加查询在数据库中执行加载相关用户,但是当用户物化EF将开始修复并验证其关系模型,并在此问题来了-它区分大小写所以根据比较字符串此设置a不等于A,因此您加载的User实体不是您的Registration实体的关系.因此,EF不会修复User1属性,它将保持为空.LastName在这种情况下访问将抛出NullReferenceException.

只有两种解决方案:

• 修复您的数据库并确保此案例差异不会再次出现在您的数据中
• 如果您在项目的开头或者您完全控制数据库重新设计它.NVarChar主键和外键都是糟糕的数据库设计.

如果这些选择都不适合您,则应避免将EF与此类数据库一起使用.