在web開發中(包括asp.net)有個特常見的需求,把一個實體執行個體(對應資料庫中的表)的欄位填充到頁面,頁面提交後把控制項中的值回填到一個實體執行個體中,提交之前對輸入驗證。例如:使用者資訊詳情顯示/修改功能。當然在實際中還會有如下需求,修改使用者密碼的時候需要再次輸入進行驗證,密碼不會直接存入資料庫而是要做hash加密等等。以前遇到這類問題,我常常是利用反射來做實體和頁面控制項之間的相互填充,大多數情況下這麼做沒問題,只是缺乏靈活,邏輯不明確。比如,再次輸入密碼這個欄位肯定不屬於資料庫表中的欄位,它只是一個邏輯上的輔助欄位而已,但是我又必須要它。所以在UserInfo這個實體裡面就會有一個PwdConfirm之類的欄位,然後通過Attribute來區分是否為資料庫表欄位。顯然這種做法味道很不好。而且實際開發中一個實體類在不同的情境下需要的邏輯輔助欄位並不一樣,有時候連欄位是否必填這種驗證要求都不一樣。所以我們死守著實體類來解決從UI到資料庫的所有應用是行不通的,而引入一個間接概念Form對象就好多了。
在django中Form就是針對一個頁面或一個應用情境而定製的“實體類”,它有自己的欄位,驗證方式,初始值,UI控制項類型等等,這樣做的好處非常明顯,驗證,UI展示都非常靈活,將Form對象裝換為一個實體也非難事。有一點點小麻煩就是要我們在需要的時候就要定義一個Form,比如LoginForm、UserForm,雖然這兩個Form都是為了處理User相關邏輯的,但是使用情境不同一個是登陸,一個使用者資訊展現。雖然說是小麻煩,這個代價還是能接受的,因為你既可以手工來定義Form中的欄位,也可以根據已有的實體類來產生Form對象。從設計模式上來說MVC中,M一般指領域對象,它本身就不應該暴露出來,而C與V之間的傳輸對象就應該是Form obj。試想我們的系統中V這一層可能有web,winform或silverlight等等。我們的Form obj就可以根據V的不同需求而產生不同的樣子。這點上單憑一個實體或領域對象可是解決不了的。
感歎啊,Form這東西簡單實用也不需要特定的文法支援(當然在.net中實現要比python中困難一些,而有c#3.0會方便一些)我怎麼就沒想到呢,看來我等小球只能慢慢體會大師們的思想了。