本人覺得寫得很有道理，值得學習。
轉自【IT168知識庫】
表單自定義功能看似非常方便，可以不用寫代碼即可完成表單的開發設計，表面上看的確是減少不少開發成本，但深入研究，發現是有不少誤區的。
1、 對于整體成本來講，當表單自定義功能能滿足實際客戶需求的60%時，會為另外的40%需求付出多少成本。現實中所見到的表單自定義工具一般至多能滿足實際客戶需求的50%。一般容易實現的僅布局、字段的增減、簡單的腳本控制等，但有很多諸如復雜腳本控制、自動計算、特殊邏輯驗證、主從關系，復雜基礎數據選擇（過濾、合并）、與其它功能模塊的交互等等需求，自定義工具都不能實現。最終可能帶來的代價是重做，甚至推翻整個系統架構重新實現，付出成本是預計成本的2-4倍以上均有可能；
2、 表單自定義功能實現的方式一般是數據庫表中預制了很多字段或者是一個表中的記錄存儲為 ID、字段名、值、字段類型，而且值的類型往往是字符型，這些做法給數據的查詢統計及SQL優化帶來的是非常大的性能損失和阻力，業務系統數據量不大的時候看不出，一旦數據業務表大到一定程度的時候，性能瓶頸就會出現。我們知道需要工作流的業務系統都是大量用戶和大規模業務數據的。對于表單自定義做法，性能瓶頸是一定要考慮的；
3、 表單自定義往往實現的是一個數據實體的增、刪、改，但對于一個系統來講一個表單僅僅是一個功能點而已，這個功能點對于整個系統來講遠不是那么單純的，有可能一個數據實體的資料分別在多個表單里進行更新和維護，自定義邏輯往往是處理不了它們之間的沖突，還有查詢和統計分析，這些是需要關聯很多基礎數據、關聯其它業務數據。自定義表單功能本身也只是從功能特性的角度去出發，對于系統復雜的實體關系、業務模式、設計模式的支持幾乎為零，一個高質量系統需要的因素基本實現不了；
4、 我們企業使用表單自定義工具的時候往往已經有了很多的系統，比如HR、CRM甚至ERP系統，我們很多關聯數據會是來自于這些系統的數據。表單自定義工具往往無法提供高可靠性的集成方案，即使能集成也是勉強的，后續會付出很多手工同步、統計口徑不一致等代價，為企業整體的信息化效果大打折扣；
5、 另外從實際的使用情況而言，我們實現一個表單自定義功能的目標往往是為了方便用戶實現自己的業務邏輯，但實際上很少客戶會自己去自定義這些表單。而開發人員都會熱忠于實現一個表單自定義工具，但不會愿意長期去做表單的定制工作，從開發人員的成長角度來說是不利的。對于團隊的管理者來說用程序員的工資去做表單配置工作也是不劃算的；
6、 透過這些現象的分析，假如我們一定要去實現一個好的表單自定義工具，一定是有很多事件接口的、一定是要能支持調試的、布局一定要能有足夠的細致、自定義過程中要有提供給業務人員的自動向導（比開發人員需要的向導更加傻瓜化）、一定能做到足夠的優化或支持優化的實現、能支持緩存、調用程序集、從WebService獲取信息、能對頁面交互過程進行優化。。。。。。這些都實現后，會發現做的表單定義工具其實就是大軟件公司研發的IDE開發環境，如：visual studio開發環境，我們是否有這個能力呢？
表單自定義工具在軟件投標過程中實現快速原型有幫助，但實際應用系統還是需要用大廠商提供的開發工具進行開發，假如一個表單自定義工具真那么容易實現的話，而且那么有用的話，為什么微軟、IBM等公司不去做這樣的工具呢？