**【it168知識庫】
表單自定義功能看似非常方便，可以不用寫**即可完成表單的開發設計，表面上看的確是減少不少開發成本，但深入研究，發現是有不少誤區的。
1、 對於整體成本來講，當表單自定義功能能滿足實際客戶需求的60%時，會為另外的40%需求付出多少成本。現實中所見到的表單自定義工具一般至多能滿足實際客戶需求的50%。一般容易實現的僅布局、欄位的增減、簡單的指令碼控制等，但有很多諸如複雜指令碼控制、自動計算、特殊邏輯驗證、主從關係，複雜基礎資料選擇（過濾、合併）、與其它功能模組的互動等等需求，自定義工具都不能實現。最終可能帶來的代價是重做，甚至推翻整個系統架構重新實現，付出成本是預計成本的2-4倍以上均有可能；
2、 表單自定義功能實現的方式一般是資料庫表中預製了很多字段或者是乙個表中的記錄儲存為 id、欄位名、值、字段型別，而且值的型別往往是字元型，這些做法給資料的查詢統計及sql優化帶來的是非常大的效能損失和阻力，業務系統資料量不大的時候看不出，一旦資料業務表大到一定程度的時候，效能瓶頸就會出現。我們知道需要工作流的業務系統都是大量使用者和大規模業務資料的。對於表單自定義做法，效能瓶頸是一定要考慮的；
3、 表單自定義往往實現的是乙個資料實體的增、刪、改，但對於乙個系統來講乙個表單僅僅是乙個功能點而已，這個功能點對於整個系統來講遠不是那麼單純的，有可能乙個資料實體的資料分別在多個表單裡進行更新和維護，自定義邏輯往往是處理不了它們之間的衝突，還有查詢和統計分析，這些是需要關聯很多基礎資料、關聯其它業務資料。自定義表單功能本身也只是從功能特性的角度去出發，對於系統複雜的實體關係、業務模式、設計模式的支援幾乎為零，乙個高質量系統需要的因素基本實現不了；
4、 我們企業使用表單自定義工具的時候往往已經有了很多的系統，比如hr、crm甚至erp系統，我們很多關聯資料會是來自於這些系統的資料。表單自定義工具往往無法提供高可靠性的整合方案，即使能整合也是勉強的，後續會付出很多手工同步、統計口徑不一致等代價，為企業整體的資訊化效果大打折扣；
5、 另外從實際的使用情況而言，我們實現乙個表單自定義功能的目標往往是為了方便使用者實現自己的業務邏輯，但實際上很少客戶會自己去自定義這些表單。而開發人員都會熱忠於實現乙個表單自定義工具，但不會願意長期去做表單的定製工作，從開發人員的成長角度來說是不利的。對於團隊的管理者來說用程式設計師的工資去做表單配置工作也是不划算的；
6、 透過這些現象的分析，假如我們一定要去實現乙個好的表單自定義工具，一定是有很多事件介面的、一定是要能支援除錯的、布局一定要能有足夠的細緻、自定義過程中要有提供給業務人員的自動嚮導（比開發人員需要的嚮導更加傻瓜化）、一定能做到足夠的優化或支援優化的實現、能支援快取、呼叫程式集、從webservice獲取資訊、能對頁面互動過程進行優化。。。。。。這些都實現後，會發現做的表單定義工具其實就是大軟體公司研發的ide開發環境，如：visual studio開發環境，我們是否有這個能力呢？
表單自定義工具在軟體投標過程中實現快速原型有幫助，但實際應用系統還是需要用大廠商提供的開發工具進行開發，假如乙個表單自定義工具真那麼容易實現的話，而且那麼有用的話，為什麼微軟、ibm等公司不去做這樣的工具呢？
工作流自定義表單 玩具還是雞肋
最近見過幾個包含工作流方面的招標檔案，使用者無一例外，都把自定義表單作為考核標準之一。不知道是他們接觸的oa軟體廠商宣傳資料過多，還是確確實實，有那麼迫切想自定義表單，走幾個流程來試試的強烈意願。而目前技術上實現自定義表單，不外乎兩種模式。第一種是將業務表單所有資訊作為字段資訊儲存在單一資料庫表中，...
工作流軟體的自定義功能
我們在實踐中也許體會到即使同為流程型的行業，不同型別的企業對應用系統也有不同的需求側重。正如方木不可配圓孔一樣，不要指望乙個針對牛奶企業的管理系統能在紡織廠得到成功應用。從中我們可以想到乙個工作流軟體如果沒有自定義功能靈活去配置自己的應用將會很被動。那麼工作流軟體的自定義功能用途就顯而易見了，強大的...
工作流定義
工作流 這個概念並不為大多數人所了解，即使是在專業的軟體開發人員中，工作流 這三個字也是遠遠比不上 dbms 這樣的術語為人熟悉和使用的程度，這並不是說工作流技術不及 dbms 等技術，只是說明了工作流技術相對於 dbms 等成熟 穩定的技術來說，還處於發展的初期。工作流是一種反映業務流程的計算機化...