前段時間北京來了幾個技術顧問幫忙分析公司的乙個專案的轉換方案，無意間談到了xml的這個話題。兩位專家分析的好，xml是個好東西，但是如果濫用的話那麼系統肯定就廢了，公司的程式設計師也認同，因為以前做的乙個查詢，轉換成xml以後有1個多g的資料，就別提效率了。另外，對於xml的解析多少會影響到效率，如果處處都用xml的話，效果可想而知。
記得以前做過乙個專案，是有cs和bs兩個部分，其中有一塊申報表單需要winform和webform一起來做，而考慮到其申報表單的不確定性，政務部門的都這樣，所以表單的內容就用xml來描述，這個想法起初很好，可是後來cs那頭換了個程式設計師，感覺這xml就變了味了。因為以前好歹xml也是遵循一定格式的用dtd也能判斷出其是否符合標準，而到後來這個xml乾脆就是成了描述winform裡有啥的乙個工具，核取方塊列表也變成了這樣的組合，當然這麼bs不是不能解析，而是偏離了原先的設計初衷，申報表單的元素不封裝一下直接就拿控制項來描述，一來亂，而來解析困難，因為還要過濾掉很多bs不支援的控制項
總之我分析失敗點所在，就是xml的描述，應該是以申報表單的元素為單位，對於每乙個表單元素有基於winform控制項集合的封裝，而不是以winform控制項為單位的對窗體的描述。
基於前者，xml的體積會小那是定了，另外任何乙個程式拿過來解析起來也會很容易，不用挨個的過濾。
回頭思考關於xml的使用
前段時間北京來了幾個技術顧問幫忙分析公司的乙個專案的轉換方案，無意間談到了xml的這個話題。兩位專家分析的好，xml是個好東西，但是如果濫用的話那麼系統肯定就廢了，公司的程式設計師也認同，因為以前做的乙個查詢，轉換成xml以後有1個多g的資料，就別提效率了。另外，對於xml的解析多少會影響到效率，如...
關於xml使用的感悟
新建xml檔案的情況可能不多，但對節點 屬性的增刪改查會很常見 這兩句應該很常用的，載入已經存在的xml文件。xmlnode root 根節點 root xmldoc.documentelement 獲取根節點 這個用來獲取xml的根節點 xmlnodelist nodelist xmldoc.se...
關於佇列使用的思考
今天不寫 分享一下關於佇列的思考。高併發在我們的工作當中是乙個經常遇到的問題，一般資料庫效能依賴於硬體，自身並沒有對併發進行控制，更多的時候我們需要從程式設計的角度控制併發，根據伺服器的效能來控制併發量。如果壓力過載，輕則執行如龜速，重則程式崩潰。下面有這樣乙個場景，有一堆待執行的任務a b c d...