微型專案實踐（1）用XML描述實體

系統設計的第一步當然是分析需求，目前能夠想到的就是對日誌的管理，恩……再加上乙個分類好了，大體就是這樣子：

我們使用乙個xml來描述這兩個實體：

1:  
xmlversion
="1.0"
encoding
="utf-8" ?>

2:  
<
entities
xmlns
="">

3:  
<
entity
title
="日誌"
name
="blog"
module
="blogs"
>

4:  
<
item
title
="標題"
name
="title"
type
="text"
require
="true"
/>

5:  
<
item
title
="內容"
name
="content"
type
="longtext"
require
="false"
/>

6:  
<
item
title
="所屬分類"
name
="blogclass"
type
="entity"
entityname
="blogclass"
require
="false"
/>

7:  
<
item
title
="建立時間"
name
="createdatetime"
type
="datetime"
require
="true"
/>

8:  
<
item
title
="更新時間"
name
="updatedatetime"
type
="datetime"
require
="true"
/>

9:  
entity
>

10:  
<
entity
title
="日誌分類"
name
="blogclass"
module
="blogs"
>

11:  
<
item
title
="名稱"
name
="name"
type
="text"
require
="true"
/>

12:  
<
item
title
="描述"
name
="description"
type
="text"
require
="false"
/>

13:  
entity
>

14:  
entities
>

這個xml很容易看懂，它的schema定義在「」中，根節點表示這個xml定義的是實體的集合（entities）。每乙個實體包含很多資料字段，欄位有標題、名稱、型別等屬性，需要注意的是，這裡的資料字段不表示資料庫設計，也不表示類的設計，只是實體的業務邏輯定義。

使用xml描述業務資料有很多好處：

是與具體實現無關。正如前面說的，該xml描述的是業務實體，不是資料庫表，也不是c#類，所以它是與具體實現無關的。我們需要的僅僅是描述系統的業務邏輯所包含的資料有哪些，以及他們的相互關係是什麼。所以這種描述方法甚至可以推廣到其它平台。

無二意性的。與需求文件不同，xml描述的定義是精確的，不會因為措辭的不同造**們不同的理解。

是可以被版本控制的。xml是純文字的，它被包含在專案的solution中，當然會被版本控制工具一併捕獲。版本控制的好處在於不同的版本的**對應不同階段的業務需求，這直接表示為不同的資料庫設計，因此避免了團隊成員修改了資料庫而其它成員的**不能執行的問題。

使專案自動化。有了描述實體的xml能幹什麼？很多：生成資料庫的建庫指令碼，生成實體c#類，生成測試資料，甚至可以用於生成文件和專案手冊！這可以大大提高系統的開發效率，規模越大的系統，自動化的優勢越明顯！

是同步的。文件的更新與同步經常成為乙個令人頭疼的問題。而這個xml因為是系統框架自動化的依據，所以修改系統需求和設計時，這個xml是被同步修改的，所以這個文件總是可以被作為了解系統設計的最新資料。

因為以上這些優勢，所以我總是以這個xml作為專案的起點。當然，xml的格式也可以根據專案的不同，略做修改。

微型專案實踐（1） 用XML描述實體