關於理想化的編程

      理想化編程測例子還不少，我就拿作接口這個例子說事吧！

      如今通常的接口都是給的json格式，Json是一種特殊的字符串（就像string是特殊的引用類型，至於怎樣特殊問題留給你了）！XX提供一個接口是一個字符串，而後我問是怎麼搞得，他說拼接，此時此刻，你們以爲有問題嘛？

      你拼接Json串，總有一天你會感受到日了狗。。。。（包括在js拼接json串也是同樣，必定要拼json對象！必定要拼json對象！必定要拼json對象！重要的事情說三遍！而後再用JSON.parse()和JSON.stringfy()去操做。

      XX提供的結構就是一串字符串，爲何不序列化！！！！出現佔位符怎麼樣？XX曰：咱們數據不會出現！這麼確定？這就是理想化編程的可怕！

      我跟到底層原來寫的這麼鬼：

     public string ToJson()
        {
            return string.Format("{{\"para1\":{0},\"para2\":{1},\"para3\":{2}}}", para1, para2, para3);
        }

      此時我已無力吐槽。。。。爲何不序列化(Serialization)成json?

      下面還有關於反序列化成model。爲何用強轉？強轉爲何不加Try catch？

       LModel codelist = (Model)JsonConvert.DeserializeObject(strJson, typeof(Model));

      其實也不必用Try catch，用as就行

      關於強轉和as的區別：強制類型轉換：轉換不成功會拋出異常，對引用類型和值類型都適用。as運算符：轉換不成功獲得一個null值，不會拋出異常；僅適用於引用類型，不能用於值類型。

      LModel codelist = JsonConvert.DeserializeObject(strJson, typeof(Model)) as model;

     這不就OK了。。。。

     作接口要注意的地方（一家之言，歡迎拍磚）：

     1，標準的接口文檔和標準的接口數據；

     2，性能；

     a、SQL語句性能，查詢更快

     b、緩存，減小數據庫壓力

     c、數據量，能不能一次把數據拿出來

     d、生成壓縮gz文件，減小網絡傳輸

     先以json爲例吧，像編程理想化的例子還不少，好比不寫後端驗證，咱們改怎麼防護攻擊。此恨綿綿無絕期，吾將上下而求索！我是否是有點較真了？？？？