在这里，我需要感谢一下“异或”运算符，真的，谢谢你，^（xor），如果没有它，也许我架构里总是离不开否定式，如果你看不懂我说的，那让先看看这篇文章，事实上那篇文章没有解决根本的否定式问题，题目也只是对DefaultValue的一个学习，这篇文章，我认为终于把“否定式“解决了，真的解决了！

这是我的架构代码，否定式的出现是为了让程序员少写代码

 public interface IUnitOfWork
    {
        /// <summary>
        /// 将操作提交到数据库，
        /// </summary>
        void Save();
        /// <summary>
        /// 是否不提交到数据库，这只是在具体的repository类中的SaveChanges方法里用到的
        /// 默认应该设置为false，即默认为提交到数据库
        /// </summary>
        /// <returns></returns>
        bool IsNotSubmit { get; set; }
    }

当你的数据上下文实现IUnitOfWork接口后，不需要为IsNotSubmit 再赋值，你只要实现一下getter,setter就可以了，但代码看上去是不漂亮的，因为代码的含义

是一种“否定式”，我们一般会把它解释为：没有提交，而在程序中，我们希望它是提交的，会这样写代码

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

意思是说，如果不是被不提交的（即提交的），就保存动作，这个解释对我们来说是不容易理解的，我们一般叫它否定式的，为什么不用IsSubmit，因为bool类型默认值是false，如果你用issubmit，那就是默认为“不提交”动作，而我需要的是“默认提交”，而我又不希望每个上下文在实现时，都去把IsSubmit赋为true，因为这样

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

Xor的出现，让我彻底摆脱“否定式”

异常的含义大家都知道，相同为假，相异为真，呵呵，但却没有用在它需要的地方，这是我们国人的通病，即只知道这个东西，但却不知道如何用好它。

看我的代码，使用xor，把isnotsubmit改为issubmit，呵呵

  public interface IUnitOfWork
    {
        /// <summary>
        /// 将操作提交到数据库，
        /// </summary>
        void Save();
        /// <summary>
        /// 是否需要显示进行提交（save()）
        /// 默认为false，即在repository方法中自动完成提交，值为true时，表示需要显示调用save()方法
        /// </summary>
        /// <returns></returns>
        bool IsSubmit { get;set; }

    }

注意看下面的判断，它是核心，事实上是程序处理的一个小技巧

 if (db.IsSubmit ^ true)//IsSubmit为true时，不自动执行save()方法
       db.Save();

我们让IsSubmit与true作一个异或运算，通过概念我们如果，当issubmit为false时，条件才为真，而bool类型默认值就是false，所以，咱们的程序完美了，默认就提交了，而且我的属性是IsSubmit ，而不是IsNotSubmit ，呵呵，终于摆脱“否定式”，呵呵！

再次感谢xor，感谢异或！

本文转自博客园张占岭（仓储大叔）的博客，原文链接：将不确定变为确定~感谢异或，是你让我彻底摆脱“否定式”，如需转载请自行联系原博主。