在 C# 中 ("x" == "X") 何时成立？
这个问题初看起来很奇怪，C#就是C#啊，一门严谨的语言，并且字符串是区分大小写的，无论是在什么情况下都有("x" != "X")，这才叫做一致性嘛。事实上，这在以前一直都是成立的，直到.NET Framework 3.5引入了Linq to Sql，这种一致性就被破坏掉了，变成依赖于环境配置了。
想象一下我们对一个Linq to Sql的DataObject编写一个Linq查询，并且where子句包括("x" == "X")，那么该子句会返回true还是false呢？事实上，该查询虽然是一个用C#编写的lamda表达式，然而并不编译为MSIL。Linq to Sql里面的Linq是直接编译为SQL语句的，因此("x" == "X")会直接变成SQL里面的("x" = "X")。那么这就为true了？也不对，因为大小写是否敏感是基于数据库配置的，在当前的应用程序连接上特定的数据库之前，这个问题的答案都是不确定的。
那么我们可否选择使用String.Compare()来强制设置是否大小写敏感？这在Linq to Object中没问题，在Linq to Sql中就不行了，因为String.Compare()无法编译为SQL语句。因此，在Linq to Sql中，大小写是否敏感是一个依赖于环境配置的，这就提高了编码过程中由于疏忽而造成问题的概率。
为什么这样说呢？在以前，我们的C#代码和 SQL代码是分开书写的，写C#的时候就很明确大小写敏感，写SQL的时候就很明确是数据库相关的。然而现在部分的SQL逻辑改为用C#来编写了，问题就 出现了，特别是当你的代码中还混杂有Linq to Object的查询时，编写代码与阅读代码的过程中你一看到Linq就先要去想这段lamda表达式最终会被编译为哪种语言，MSIL还是SQL。如果你 不进行这个区分，或者开小差把Linq to Sql的代码当作Linq to Object了，这就可能导致你编写了错误的代码，或者阅读上造成了错误的理解。
总体而言，虽然Linq to Sql为开发（特别是RAD）带来了巨大的便捷性，然而这种C#与SQL混合编写并且都使用C#语法的功能将会是一种先天的不足，它所带来的代码维护成本可能随着项目体积逐步增大而慢慢体现出来。
想象一下我们对一个Linq to Sql的DataObject编写一个Linq查询，并且where子句包括("x" == "X")，那么该子句会返回true还是false呢？事实上，该查询虽然是一个用C#编写的lamda表达式，然而并不编译为MSIL。Linq to Sql里面的Linq是直接编译为SQL语句的，因此("x" == "X")会直接变成SQL里面的("x" = "X")。那么这就为true了？也不对，因为大小写是否敏感是基于数据库配置的，在当前的应用程序连接上特定的数据库之前，这个问题的答案都是不确定的。
那么我们可否选择使用String.Compare()来强制设置是否大小写敏感？这在Linq to Object中没问题，在Linq to Sql中就不行了，因为String.Compare()无法编译为SQL语句。因此，在Linq to Sql中，大小写是否敏感是一个依赖于环境配置的，这就提高了编码过程中由于疏忽而造成问题的概率。
为什么这样说呢？在以前，我们的C#代码和 SQL代码是分开书写的，写C#的时候就很明确大小写敏感，写SQL的时候就很明确是数据库相关的。然而现在部分的SQL逻辑改为用C#来编写了，问题就 出现了，特别是当你的代码中还混杂有Linq to Object的查询时，编写代码与阅读代码的过程中你一看到Linq就先要去想这段lamda表达式最终会被编译为哪种语言，MSIL还是SQL。如果你 不进行这个区分，或者开小差把Linq to Sql的代码当作Linq to Object了，这就可能导致你编写了错误的代码，或者阅读上造成了错误的理解。
总体而言，虽然Linq to Sql为开发（特别是RAD）带来了巨大的便捷性，然而这种C#与SQL混合编写并且都使用C#语法的功能将会是一种先天的不足，它所带来的代码维护成本可能随着项目体积逐步增大而慢慢体现出来。
