在這裡，我需要感謝一下“異或”運算符，真的，謝謝你，^（xor），如果沒有它，也許我架構裡總是離不開否定式，如果你看不懂我說的，那讓先看看這篇文章，事實上那篇文章沒有解決根本的否定式問題，題目也只是對DefaultValue的一個學習，這篇文章，我認為終於把“否定式“解決了，真的解決了！
這是我的架構代碼，否定式的出現是為了讓程序員少寫代碼
summary
summary summary
summary
當你的數據上下文實現接口後，不需要為再賦值，你只要實現一下getter,setter就可以了，但代碼看上去是不漂亮的，因為代碼的含義
是一種“否定式”，我們一般會把它解釋為：沒有提交，而在程序中，我們希望它是提交的，會這樣寫代碼
();
意思是說，如果不是被不提交的（即提交的），就保存動作，這個解釋對我們來說是不容易理解的，我們一般叫它否定式的，為什麼不用IsSubmit，因為bool類型默認值是false，如果你用issubmit，那就是默認為“不提交”動作，而我需要的是“默認提交”，而我又不希望每個上下文在實現時，都去把IsSubmit賦為true，因為這樣
程序員不干了，程序本身也不漂亮，所以，我才用了isnotSubmi——這是使用它的原因...
Xor的出現，讓我徹底擺脫“否定式”
異常的含義大家都知道，相同為假，相異為真，呵呵，但卻沒有用在它需要的地方，這是我們國人的通病，即只知道這個東西，但卻不知道如何用好它。
看我的代碼，使用xor，把isnotsubmit改為issubmit，呵呵
summary
summary summary
summary
注意看下面的判斷，它是核心，事實上是程序處理的一個小技巧
(db.IsSubmit ();
我們讓IsSubmit與true作一個異或運算，通過概念我們如果，當issubmit為false時，條件才為真，而bool類型默認值就是false，所以，咱們的程序完美了，默認就提交了，而且我的屬性是IsSubmit ，而不是IsNotSubmit ，呵呵，終於擺脫“否定式”，呵呵！
再次感謝xor，感謝異或！
