網站後台管理UI設計裏,通常Table項目維護都使用「Grid」列表方式作列表維護,遇到階層式或Master-Details的顯示,傳統的子層跳頁或內嵌顯示方式,都會讓整個UI介面顯得不夠清爽。
對User而言,要表現出資料的階層式關係即可,介面上儘量力求簡單。對Programmer而言,頁面程式要好複製,利用DB Hierarchy架構可以共用相同的Table,而下方的UI設計Pattern可以求得平衡。
例如要開發Master-Details架構,只要複製ASPX頁面,設定好頁面的隱藏Key值, 設計好右側頁面的UI控件呈現,基本的CRUD架構就形成。
左側樹狀選單使用AJAX方式,動態取子層的項目列表,而且可以透過滑鼠左鍵拖曳讓Item在階層裏移動、改變顯示順序。遇到複雜的項目維護,拉到磞出的Window視窗再作操作。
此Pattern因採用樹狀選單UI來表達階層式視覺分類(若子項多的話,宜用Grid+條件搜尋來操作),比起傳統的一層List顯示方式或Master-Details Grid,會更清楚,且支援更複雜的表單內容設計。
考量開發成本及Reuse效益,我習慣在ASPX頁面作很多隱藏參數設定,程式員只要調整其值,即可符合多數的資料維護管理需求。至於DB設計,所有網站只需要一個Table即可,即使為了資料維護便利拆分成不同Table,其實Schema架構都差不多。
至於是否要使用程式產生器(Code Generator)產生這些程式碼,其實DB及UI都一致,使用人工方式複製、修改+客製化校正,跟產生器設定時間上都差不多。除非有大量重複性客源開發需求,否則也不太需要。
總言之,UI的呈現還是要看客戶需求而定,這個Pattern只是少量分類項目Table維護的一種UI呈現而己,特別適合「分類項目」的資料維護。對沒耐心的程序員來說,這種小Table的CRUD程式很簡單,但卻是一再重複的Dirty Work,特別會扼殺編程樂趣。對客戶來說,傳統的Grid列表較無法簡單呈現資料分類設計,更無法視覺上讓項目在分類間裏移動,而這UI Pattern正因此而生。