初看ASP.NET MVC 3(參見初體驗 1 2 3 4)讓人興奮,但畢竟技術只是工具,因學習探索產生的激情不能當飯吃,是否能建立順暢的開發流程,切實滿足工作專案的需求,才是我這種現實鬼決定技術是否值得長期投資的關鍵。平日開發的系統,幾乎都繞著資料的新增/修改/刪除打轉(就是傳說中的CRUD,Create/Read/Update/Delete),因此評估過程中我最關注的,便是ASP.NET MVC建構資料維護介面的難易度與擴充空間。

在上週的範例中,ASP.NET MVC露了一手: 先寫Model類別設好屬性,透過Scaffolding自動展成編輯畫面,依著屬性上的[Require][Range(...)] Attribute,便可在存入資料前,檢核輸入值是否合法有效,甚至最過分的,連Javascript端欄位驗證都已自動加上。

想想之前為了處理欄位檢核,得分別在Javascript與Server端各寫一堆Code,更煩人的,若開發人員偷懶或疏忽少寫了檢核程式,就可能發生該檢查未檢查,錯放無效資料流入後端的狀況。相較之下,透過Model欄位的Attribute註記檢核條件,透過統一機制去實現Client端及Server端的驗證,而非仰賴每個開發人員自行注意大小細節,顯然是更能有效維持程式品質的做法,而這種只靠Attribute就打點好Client及Server端檢核,不需要到處複製類似程式碼的做法,也十分符合DRY(Don’t Repeat Yourself)的精神。

【黑暗守則】對於團隊開發採用的架構而言,需要Coding的地方愈少,出錯的機率就愈小

當然,我們樂見所有開發者都充滿學習熱情,隨時精益求精,不斷改善強化自己Coding的技巧。但在很多LOB(Line of Business,商務營運)系統裡,開發人員除了Coding技巧,還需要具備業務知識才能勝任,若精通LINQ、AJAX、WCF卻對損益計算毫無概念,最後搞出一套演架構好、程式美,操作順,效能佳,可惜數字有錯的帳務系統...

讓我聯想到食神裡那尊餿掉的豆腐精雕金縷佛衣:


照片截自YouTube

註定要拿零分!

LOB系統開發者如能精通Domain Knowhow,又具備精純的Coding技巧,當然是最好! 但兩種技能都很強的開發者猶如鳳毛麟角,遇到了都算前世的福報。真實世界跟Online Game蠻像的,與其苦尋可以當肉盾又會法術的弓箭手當隊友,不如找各種專長的職業、種族組支軍團,由專攻Coding的人配合專案需求打造客製架構及輔助工具,讓使用自訂架構及工具開發系統的技能需求盡可能少(相當於施放增加命中率的法術);如此讓已經具備Domain Knowhow的開發者可以不需要太深入平台、技術及語言的細節(但還是要懂基本技能,增加命中也幫不了完全不會揮劍砍刀劈斧拉弓的廢柴),就能運用它迅速實現結果正確及品質尚可的系統,滿足繁雜的中小型專案需求。(當然,這戰略只針對一般中小型副本任務,如果要打大王,還是得精選技能夠強的菁英組隊才不會滅團)

針對LOB系統開發,我一直覺得較好的做法是將開發工作分工,由專精網頁開發技術的人投注在基礎架構上,建構出可以簡便將Business Logic展現成網頁介面的框架,降低參與LOB系統開發人員的技術技能門檻,投入較多時間在Business Logic撰寫上,以便快速做出結果正確的系統。從某些角度來看,ASP.NET Web Form造就了類似的環境,想想看,開發人員完全不用懂HTML、Javascript,只要會C#/VB.NET,就能做出AJAX效果的動態網頁更新效果,你不得不說它是件神奇的事。姑且不論UpdatePanel的副作用,把它想像成讓原本寫不出AJAX的人實現"我也可以AJAX"的夢想所要付出的代價,或許就能釋懷,說來也算是功德一件吧! (但讓Javascript門外漢具備AJAX能力是一回事,打造數千人同時使用的B2C網站,則又另當別論。)

看到ASP.NET MVC的Model Binding跟Scaffolding自動生出具有Javascript端Validation功能網頁時,讓我有種: "啊! 就是要這樣"的感動,不過,若輕易相信世間有此等美好的事,就稱不上是老鳥,火力展示多半只會呈現給你光鮮亮麗的一面,至於技術或架構的限制與克服之道,就得靠自身的實務經驗去考察發掘。我印象很深,十幾年前微軟有個產品叫Visual InterDev,裡面有個特異功能,下一步下一步就可以做出一個可以自動分頁的資料庫查詢ASP網頁,看了讓人直起雞皮疙瘩。(對從ASP.NET入手的朋友來說這根本不算什麼,DataGrid就可輕易辦到,但那可是十多年前每一列<tr><td>要自己刻的年代耶~~) 不過,後來的歲月裡,我真的沒看過有人真的在專案裡用Visual InterDev提供的下一步下一步精靈製作資料庫查詢網頁,理由很簡單: 用精靈產生介面又快又炫,但若要客製網頁上的呈現細節,因少了預留擴充客製的API介面,只能自行追進Javascript設法破解,搞得我氣急攻心口吐鮮血,最後大徹大悟決定自己重寫...

因此,看到ASP.NET MVC內建的CRUD支援,第一件想做的事,便是依多年跟資料維護介面糾纏的經驗,開始設想在實務上常遇到的挑戰,檢查其擴充客製彈性是否能過關。於是,我展開"ASP.NET MVC是否能取代WebForm做為現行以CRUD為核心網站專案之開發架構?"的研究與評估,先試想了一些常見CRUD客製需求:

  1. Create/Edit畫面,常需要配合系統整體的排版要求,例如: 欄位名稱文字有一定的css設定、多個Model都有修改人員、修改時間欄位,希望呈現在固定的位置... 先產生預設版型再手工調整是可行,但能否自訂Create/Edit樣版,讓自動產生的cshtml盡可能接近最後的結果,減少手動調整的需求?
  2. @Html.EditorFor(model => model.Score)就能生出帶有Client端驗證功能的HTML TextBox很酷,但如果我要產生的是下拉選單、日期選擇器、數字欄位選擇器,用jQuery在網頁載入後再做後製是可行的,但有沒有更簡便的方法?
  3. 針對UI輸入值與Model屬性間的特殊轉換,是否能透過Model Binding自動完成? 例如: 下拉選單對應到列舉類別
  4. 預設有[Required][Range(…)][RegularExpression(…)][StringLength]等資料檢核Attribute,如果不足的話,要如何自訂? 能比照內建Attribute連Client端驗證也一起加入嗎?
  5. (...應該還有沒想到的問題,見招拆招唄...)

前陣子學會追蹤ASP.NET MVC 3 RTM Source的方法,參酌網路爬文,開始逐一思索如何用ASP.NET MVC克服上述CRUD常見的客製需求,我踏上了ASP.NET MVC 3的CRUD之路...


Comments

# by 小黑

追隨黑哥

# by mis2000lab

讀完之後,我哭了...... 是洋蔥!文章裡面加了洋蔥! 以後我讀不到這麼刻骨銘心的文章該怎麼辦啊! 寫到我心坎裡面了 我決定把這篇文章名為 -- 黯然銷魂 的 ASP.NET MVC CRUD之路 :-P

# by 米斯特‧載卡多

....十多年前每一列<tr><td>要自己刻的年代耶...;嗯? 我旁邊的年輕正妹SA 是用這種方式教我寫分頁...難到我被她年輕貌美的外表給欺騙了嗎..?

# by Jeffrey

to 米斯特‧載卡多,如果不是正妹想藉此增加跟你相處的時間,就是對方並非"妹"級(登楞! 建議你問她知不知道"謝謝口香糖"或問她有沒有聽過"有一個女孩叫甜甜.."當成測試,跟請白娘子喝雄黃酒有異曲同工之妙)

Post a comment