在这里,我需要感谢一下“异或”运算符,真的,谢谢你,^(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,感谢异或!