這個問題初看起來很奇怪，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#語法的功能將會是一種先天的不足，它所帶來的**維護成本可能隨著專案體積逐步增大而慢慢體現出來。
C 類模板在何時例項化？
影響中的一道筆試題，總結了下模板類只宣告未定義時，在哪些情況會出現編譯錯誤。1 直接例項化物件 只是宣告則不會出錯 無論用棧還是new，編譯時都會出錯。2 函式定義 只是宣告則不會編譯錯誤 中引數或返回值引用例項化該模板物件時，非引用和傳指標，編譯時會出錯。總結 定義中直接使用類模板的例項模板類而非...
C 中何時呼叫複製建構函式
在c 中，只有單個形參，而且該型別是對本類型別的引用 常用const修飾 這樣的建構函式稱為複製建構函式。複製建構函式既可以自己定義又可以像預設建構函式一樣被編譯器隱式呼叫。但大多數時候，特別是類中有指標成員的時候要實現深複製，避免淺複製時，就需要自己定義複製建構函式。那麼我們定義的複製建構函式什麼...
在介面卡中，何時呼叫getView（）方法？
getview執行的次數和getcount沒有直接的關係 getcount和你listview裡面的條目數量 行數量 有關係 getview方法執行次數取決於你螢幕上顯示幾個條目，比如你有100行 但是你一屏只能顯示5行，那麼啟動程式的時候 系統呼叫5次getview方法，當你把listview往下...