微型项目实践（3）：实体代码的生成

上两篇我们已经有了一个XML，并且根据这个XML生成了数据库，这次我们来看一下如何从这个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>

修改上用于生成数据库脚本的那个单元测试，加入以下代码：

/// <summary>
/// 构造实体代码
/// </summary>
[TestMethod, Description("构造实体代码")]
public void Util_CreateEntityCodes()
{
    var entities = getEntities();
    var baseSpace = "DongBlog.Business";
    var usingNameSpace = new string[] { "DongBlog.Common" };
    var path = Gobal.SolutionPath + @"/DongBlog.Business";

    new LinqEntityCodeGenerater().Generate(path, baseSpace, entities, usingNameSpace, false);
}

仔细看上面这段代码可以发现，在生成实体代码之前我们还有一些准备工作要做：

1. 添加DongBlog.Common类库。该类库主要包含了验证、查询的封装和诸如MD5加密、拼音首字母转换等常用的代码。具体内容可以参看代码，稍后我们会介绍一下这几个类。
2. 添加DongBlog.Business类库。这个类库就是存放业务实体代码的地方，也就是Domain Model。里面包括所有实体类的基类（Entity）以及定义数据访问的接口（IEntityDataAccess和IDatabase），Linq使我们对于数据访问的定义得到了极大的简化。以后我们会着重分析这几个类的作用。

然后运行测试，就可以生成Blog和BlogClass这两个实体了（需要手工包含到项目中）。生成后，系统的结构和相关代码可以从右边图中看到个大概。

现在，系统的结构变得有些复杂了，我们重新调理一下：

1. DongBlog.Common：基础设置，包含了通用的功能，相当于对.Net Framework的扩展。
2. DongBlog.Business：领域模型，包含各种实体及其数据访问的定义。
3. DongBlog.Test：测试，负责测试和自动化脚本。
4. YD：工具模块，各种代码生成工具，可以跨项目复用。

以上这四个模块的依赖关系如下：

  

从依赖关系中可以看到，DongBlog.Common提供基础功能，被所有模块依赖；DongBlog.Business来源于需求，只依赖于Common（虽然Business是DongBlog.Test的生成的，但是不依赖于Test，这点儿比较绕）；YD是独立于项目，当然不依赖任何项目中的模块；DongBlog.Test的就比较惨了，它依赖于所有的模块。这个依赖关系图我们会随着项目的进行，不断完善。

抛掉Common这个半辅助性的模块不看，我们可以发现Business的才是系统的核心，因为业务逻辑来源于需求，决定了系统的其它模块，系统剩余部分围绕业务逻辑构建。目前这个图模块比较少，还没有很好的体现出这一点，在我们加入了数据访问和UI层之后，这个依赖关系会变得更加明显。

接下来的几篇我们将会逐步介绍Common中的一些类和Entity这个核心类，以及这些类的设计思路。

本篇代码下载