換個角度做設計：基於schema的全域業務資料定義。

在傳統的大型項目中，一個業務建模後，在實施階段資料定義會重複的分解到下面幾個地方：
1. 資料庫
2. 資料層的Entity或者DTO
3. Service層的傳輸對象
4. 表現層的資料
5. 使用者錄入
6. 報表等其它應用。。。

上面每個層次都要定義自己的資料格式，驗證方法，這是多麼重複而又沒有意義的勞動。
而且受到每個環節定義能力的影響，資料的驗證和意義不一定能體現出原有的需求。

那麼，誰是終結者呢？schema!

schema是dtd的晚輩，但是更強大，靈活。我們知道，一般說來schema僅僅用於定義xml並且驗證xml。
但是schema也提供了擴充空間，就是annotation. 在annotation下面，可以定義
document，document是對schema的註解。另外一個掛在annotation下面的是appInfo，從名字看，
這是給應用程式提供資訊的空間。從schema定義看appInfo可以不受限制的存放各種xml資料。

這是我的一個例子：
 <xs:complexType name="customer">
  <xs:annotation>
   <xs:appinfo source="meta">
    <meta:appInfo xmlns:meta="http://steeven.org/meta">
     <meta:title>客戶</meta:title>
     <meta:tip>下訂單的客戶</meta:tip>
     <meta:help>產生交易的下單客戶</meta:help>
    </meta:appInfo>
   </xs:appinfo>
  </xs:annotation>
  .....
  ..... //這裡是type的定義
 </xs:complexType>
可以看到，在定義一個customer的時候，我們可以為其加上meta資訊，告訴程式，這個資料的名稱，tip，協助。
如果需要，甚至可以定義協助連結，輔助輸入的資料來源，輔助選擇的控制項名稱。
這些meta元資訊，無疑為調試，介面，UI，報表等情境提供了寶貴的資訊，使畫面自動產生成為可能。

那麼一個全域的schema定義有什麼好處呢？
1. 從上面的幾個情境看，利用schema產生上面幾個情境所需的代碼易如反掌。這些代碼帶有自描述，驗證。重要的是，層間傳輸的不再是毫無意義的數字和文本，它們是活的。
2. schema支援schema之間的引用，type的重定義或者擴充。重用或重組已有定義將十分容易，並且annotation可以被繼承。
3. schema是語言無關的，意味著什麼呢？schema定義可以用不同語言實現。
4. 配上規則引擎是業務層，配上基於schema的畫面產生就是使用者介面。配上xml資料庫，儲存問題也解決。

兩年前，我曾經做過一次半成功的嘗試。我先定義了全域業務資料schema, 然後產生了資料庫schema，
當然資料庫schema引用了業務schema,　因為業務schema是源頭。
接下來，因為是個b/s項目，我又定義了畫面的request　schema和response schema。
有了這些schema剩下的任務就很簡單：根據資料庫schema, 產生了sql建庫指令碼。
根據request　schema和response schema，前台人員製作了xsl，用於轉換xml成網頁。
response schema用於校正業務層的xml輸出。並且這兩個schema都產生了樣本資料，用於前台人員後後台人員獨立調試。
由於schema引用, 設計做的快速，語意準確，甚至很多描述直接寫進了schema的annotatiion。
但是也有不盡人意的地方，比如當時我們自己定義了schema到Bean的轉換規則，並且手寫了bean代碼。
並且開發人員學習xslt和理解schema也花了點時間。

現在的開發人員很幸福，各種基於schema的工具有很多選擇。

從長遠看，直接儲存xml，利用規則引擎，基於schema動態使用者畫面將是發展方向。代碼幾乎可以銷聲匿跡。

總結一下：
1.基於schema的全域資料定義即保證了資料定義在全域的一致。
2.提供了代碼產生的基準，產生式的代碼大大減少了開發和變更的成本。
3.基於schema的動態產生是最高理想。

參考資料：
schema spec
xmlbeans
.net schema文檔
jaxme

@TODO:
動態echo/swing/swt畫面產生。
schema appInfo寫作工具。
其它代碼轉換工具