微型项目实践（1）：用XML描述实体

系统设计的第一步当然是分析需求，目前能够想到的就是对日志的管理，恩……再加上一个分类好了，大体就是这样子：

我们使用一个XML来描述这两个实体：

<?xml version="1.0" encoding="utf-8" ?>
<Entities xmlns="http://it.ouc.edu.cn/EntityDescription/V2">
  <Entity title="日志" name="Blog" module="Blogs">
    <Item title="标题" name="Title" type="text" require="true"/>
    <Item title="内容" name="Content" type="longtext" require="false"/>
    <Item title="所属分类" name="BlogClass" type="entity" entityName="BlogClass" require="false"/>
    <Item title="创建时间" name="CreateDateTime" type="datetime" require="true"/>
    <Item title="更新时间" name="UpdateDateTime" type="datetime" require="true"/>
  </Entity>
  <Entity title="日志分类" name="BlogClass" module="Blogs">
    <Item title="名称" name="Name" type="text" require="true"/>
    <Item title="描述" name="Description" type="text" require="false"/>
  </Entity>
</Entities>

这个XML很容易看懂，它的Schema定义在“http://it.ouc.edu.cn/EntityDescription/V2”中，根节点表示这个XML定义的是实体的集合（Entities）。每一个实体包含很多数据字段，字段有标题、名称、类型等属性，需要注意的是，这里的数据字段不表示数据库设计，也不表示类的设计，只是实体的业务逻辑定义。

使用XML描述业务数据有很多好处：

1. 是与具体实现无关。正如前面说的，该XML描述的是业务实体，不是数据库表，也不是C#类，所以它是与具体实现无关的。我们需要的仅仅是描述系统的业务逻辑所包含的数据有哪些，以及他们的相互关系是什么。所以这种描述方法甚至可以推广到其它平台。
2. 无二意性的。与需求文档不同，XML描述的定义是精确的，不会因为措辞的不同造成人们不同的理解。
3. 是可以被版本控制的。XML是纯文本的，它被包含在项目的Solution中，当然会被版本控制工具一并捕获。版本控制的好处在于不同的版本的代码对应不同阶段的业务需求，这直接表示为不同的数据库设计，因此避免了团队成员修改了数据库而其它成员的代码不能运行的问题。
4. 使项目自动化。有了描述实体的XML能干什么？很多：生成数据库的建库脚本，生成实体C#类，生成测试数据，甚至可以用于生成文档和项目手册！这可以大大提高系统的开发效率，规模越大的系统，自动化的优势越明显！
5. 是同步的。文档的更新与同步经常成为一个令人头疼的问题。而这个XML因为是系统框架自动化的依据，所以修改系统需求和设计时，这个XML是被同步修改的，所以这个文档总是可以被作为了解系统设计的最新资料。
6. 与客户交流的工具。就我的经验来看，大部分客户其实是想了解系统设计的，这样让他们更有安全感，也使项目的设计更符合需求。但是，数据库设计通常包含了太多的实现细节，不适合直接展示给客户，代码就跟不用说了，而这种纯粹描述业务的XML则非常合适。当然，一定的讲解是必须的，但剩下的写文档的工作。:)

因为以上这些优势，所以我总是以这个XML作为项目的起点。当然，XML的格式也可以根据项目的不同，略做修改。

当然，这个东西有些简单了，但是随着开发的进一步的进行，我们的实体数据也会逐渐增加，而增量开发、应对变化是系统设计中要解决的重要问题！实际项目的XML最终会非常复杂，这里有一个实际项目的实体XML文件，供大家参考。

当前项目的代码从这里下载。其中YD（我的名字的所写，呵呵）类库是我常用的一些代码，主要就是基于XML的代码生成器以及XML的Schema（有了它，VS.Net 2008就可以在编辑XML时启动智能感知，非常方便。）本文先到这里，下一篇中，我们来看这个XML的具体用法。