階層式項目(Hierarchy)網頁設計Pattern

網站後台管理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正因此而生。