將不確定變?yōu)榇_定~感謝異或，是你讓我徹底擺脫“否定式”

在這里，我需要感謝一下“異或”運(yùn)算符，真的，謝謝你，^（xor），如果沒有它，也許我架構(gòu)里總是離不開否定式，如果你看不懂我說的，那讓先看看這篇文章，事實(shí)上那篇文章沒有解決根本的否定式問題，題目也只是對(duì)DefaultValue的一個(gè)學(xué)習(xí)，這篇文章，我認(rèn)為終于把“否定式“解決了，真的解決了！

這是我的架構(gòu)代碼，否定式的出現(xiàn)是為了讓程序員少寫代碼

 public interface IUnitOfWork
    {
        /// <summary>
        /// 將操作提交到數(shù)據(jù)庫，
        /// </summary>
        void Save();
        /// <summary>
        /// 是否不提交到數(shù)據(jù)庫，這只是在具體的repository類中的SaveChanges方法里用到的
        /// 默認(rèn)應(yīng)該設(shè)置為false，即默認(rèn)為提交到數(shù)據(jù)庫
        /// </summary>
        /// <returns></returns>
        bool IsNotSubmit { get; set; }
    }

當(dāng)你的數(shù)據(jù)上下文實(shí)現(xiàn)IUnitOfWork接口后，不需要為IsNotSubmit 再賦值，你只要實(shí)現(xiàn)一下getter,setter就可以了，但代碼看上去是不漂亮的，因?yàn)榇a的含義

是一種“否定式”，我們一般會(huì)把它解釋為：沒有提交，而在程序中，我們希望它是提交的，會(huì)這樣寫代碼

         if (!iUnitWork.IsNotSubmit)
         　  iUnitWork.Save();

意思是說，如果不是被不提交的（即提交的），就保存動(dòng)作，這個(gè)解釋對(duì)我們來說是不容易理解的，我們一般叫它否定式的，為什么不用IsSubmit，因?yàn)閎ool類型默認(rèn)值是false，如果你用issubmit，那就是默認(rèn)為“不提交”動(dòng)作，而我需要的是“默認(rèn)提交”，而我又不希望每個(gè)上下文在實(shí)現(xiàn)時(shí)，都去把IsSubmit賦為true，因?yàn)檫@樣

程序員不干了，程序本身也不漂亮，所以，我才用了isnotSubmi——這是使用它的原因...

Xor的出現(xiàn)，讓我徹底擺脫“否定式”

異常的含義大家都知道，相同為假，相異為真，呵呵，但卻沒有用在它需要的地方，這是我們國人的通病，即只知道這個(gè)東西，但卻不知道如何用好它。

看我的代碼，使用xor，把isnotsubmit改為issubmit，呵呵

  public interface IUnitOfWork
    {
        /// <summary>
        /// 將操作提交到數(shù)據(jù)庫，
        /// </summary>
        void Save();
        /// <summary>
        /// 是否需要顯示進(jìn)行提交（save()）
        /// 默認(rèn)為false，即在repository方法中自動(dòng)完成提交，值為true時(shí)，表示需要顯示調(diào)用save()方法
        /// </summary>
        /// <returns></returns>
        bool IsSubmit { get;set; }

    }

注意看下面的判斷，它是核心，事實(shí)上是程序處理的一個(gè)小技巧

 if (db.IsSubmit ^ true)//IsSubmit為true時(shí)，不自動(dòng)執(zhí)行save()方法
       db.Save();

我們讓IsSubmit與true作一個(gè)異或運(yùn)算，通過概念我們?nèi)绻?dāng)issubmit為false時(shí)，條件才為真，而bool類型默認(rèn)值就是false，所以，咱們的程序完美了，默認(rèn)就提交了，而且我的屬性是IsSubmit ，而不是IsNotSubmit ，呵呵，終于擺脫“否定式”，呵呵！

再次感謝xor，感謝異或！