上個月頭因為幻想曲同志的的造訪,使得VIEW進入了重構期。將原有的架構全部推翻，使用標准的工廠三層模式，代碼全部重寫，加入緩存依賴，簡化存儲過程，改進整個項目的容錯機制，等等。
整整一個月的奮戰總算是重構完成，在重構中仍然保持不使用框架，不使用可視化控件。其實在重構之前有些朋友強烈推薦我使用 EnterpriseLibrary, 以及 Nhibernate 作為數據訪問層框架。不過抱著學習底層知識的態度，我沒有使用，一切方法都是純手工打造。
在重構中最頭疼的就是寫實體層（valueobject），都是些簡單而繁瑣的事情，手都快搞疼。還好幻想曲推薦了李天平代碼生成器，自動生成工廠三層模式你所需要的代碼，一下效率就提高了幾倍。
在VIEW重構尾期，我接手公司一個.net項目的表現層優化。當我打開VS後，看到整屏的控件，頭大了。首先下手的就是改進Webpart，在中間發現一個微軟嚴重的BUG，就是在代碼生成後，有個TD裡面的CSS屬性Padding:5px根本沒辦法改的動，微軟也沒有提供任何方法或屬性。差不多搞了三天，終於在微軟的MSDN裡面看到一個老外非常憤慨地責備微軟的這個BUG，而微軟也承認這個是個問題，並承諾在下個版本進行改進。於是就這樣浪費了我三天時間。
不過在這三天裡卻熟悉了微軟的控件式編程方式，個人感覺確實很好用，微軟也確實為開發群體想到了很多的問題。但是這種編程方式只能象微軟說的那樣，在企業化快速開發中使用，真正想搞那種高質量產品開發過程，我奉勸別用微軟的那套方法。因為目前看到的是，在項目開發上面確實很迅速，但是在維護以及改進方面，根本就會加重負擔，反倒讓整體進度拖慢。
因為在使用控件式編程中，存在太多的不穩定因素。表現層和其他的層次最大的不同，在於它所面對的是最終用戶，而其他層次所面對的只是開發人員。所以在技術上後面的層次發展已經十分穩定，而表現層本身有著無盡地變化，我們不能過於追求模式化的開發，而忽略表現的本身。
而非控件式編程在開發期間的效率肯定很低下，但是對於後期的維護與改進卻非常的便利。至少我不會因為一個不成熟控件的BUG而需要找上幾天的問題，然後再繼續期待這個控件更新版本，當版本更新後，又要冒著新BUG出現的風險。而所以控件自定義的話，就絕對沒有這個問題存在。
我會花很多時間寫表現層控件，但是對於一般的開發團隊來說是非常勉強的。所以最近不是提出了前端架構師這個概念嗎？我想，一個高質量的項目開發裡面，應該考慮前端架構師的位置，讓前端技術與後端技術保持同樣的等級。
千萬不要忽視這個想法，項目使用控件編程方式（主要是指使用可視化控件），越往後，只能越來不受歡迎，會越多的給項目增加維護成本。
可能有些喜歡挑刺的麻煩人物會說，你要實現這麼多東西，那麼你干脆自己寫個語言好了。呵呵，這樣的人很無知和幼稚，請不要在我這裡做憤青，我是會刪這些留言的，請不要浪費精力和我理論這個，因為我前面就說了，表現層之外的技術已經非常成熟，基本上就算改動，也會保持向下兼容，但表現層想真正做到向下兼容，絕對不可能的。至少我看到微軟目前在表現層做的所謂向下兼容，都是通過JS去動態改變一些錯誤的默認屬性。這樣的方式你會接受嗎?
