在 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#文法的功能將會是一種先天的不足，它所帶來的代碼維護成本可能隨著項目體積逐步增大而慢慢體現出來。