这里的实体类更倾向于数据传输对象（既DTO）。无论是编码风格采用 事务脚本 还是 领域模型，我们都会遇到各种各样的数据传输对象，尤其是传统事务脚本三层架构的编码中，更会遇到各类实体对象，一般来说，这些实体对象产生的原因如下：

1：为各类报表和查询服务的联表查询，会导致字段变多，带来的实体的属性增多。怎么办，创造新的实体类或者为原有实体类新增字段？

2：前台不同的需求场合，会构建不同的 DTO 对象（如JSON对象）传递到后台，新的对象产生就创造新的实体类或者为原有实体类新增字段？

我们大多会遇到以上这类问题。以下是避免创建新的实体类或者为原有实体类新增字段的一些措施。

先来看第一种情况。

一：联表查询中的字段增多

这是从里（数据层）发散到外（UI层）的过程。

以往我们像这样编码：

public override IList<User> GetList()
{
    string sql = "select * from [EL_Organization].[User] where state=1";
    var ds = SqlHelper.ExecuteDataset(
        SqlHelper.ConnectionString,
        CommandType.Text,
        sql);
    return DataTableHelper.ToList<User>(ds.Tables[0]);
}

现在，我们利用匿名类型：

public IEnumerable GetList2()
{
    string sql = "select * from [EL_Organization].[User] where state=1";
    var ds = SqlHelper.ExecuteDataset(
        SqlHelper.ConnectionString,
        CommandType.Text,
        sql);

var oblist = new List<object>();
    foreach (DataRow row in ds.Tables[0].Rows)
    {
        oblist.Add(new { Id = row["Id"], Name = row["Name"] });
    }

return oblist;
}

你可能注意到两点变化，

第一：我们原先使用泛型+反射的方法（通用方法，不赘述），直接返回了 IList<User>，而现在，我们没有这样的通用方法了，只能通过一个 foreach 循环自己来构建这样的匿名类型及其列表。你可能会首先担心循环中的那些代码繁琐而机械，但是这一定比创建一个新类型来的简单。其次，你可能会想到改造原先的泛型+反射方法，使其支持匿名类型，但当我写完这个函数的时候，我有点担心其效率，所以我仍旧推荐上面的写法。

第二点变化：返回类型是一个 IEnumerable 了，替代了原先的 IList<User>。这仿佛牺牲了一些原先作为强类型的特性，但这些特性是可克服的。有一种做法是，将返回类型修改为 IList<dynamic>，不过这仍旧带来一点点性能损耗，因此我仍旧建议，如无特殊必要（如：在业务层需要对返回结果进行赋值），返回 IEnumerable 已足够。

现在，Dal 层已经是这样，上次调用者该如何用，以 MVC 中的控制器为例，我们应该如下使用（备注，下面这个方法针对是上层返回类型是一个 IEnumerable ，如果返回 List<dynamic>，则参考“ExpandoObject对象的JSON序列化” ）：

public JsonResult xTest()
{
    UserDal dal = new UserDal();
    var list = dal.GetList2();
    return this.Json(list, JsonRequestBehavior.AllowGet);
}

你可能会觉得，这太简单，直接从 DAL 层取出来，就丢给前台了。没错，在事务脚本编码时，很多时候就是这么简单，即便仍旧要对 DAL 返回值做特殊处理，采用匿名类型也不会阻止我们什么事情。

二：构建不同的对象（如JSON对象）传递到后台

我们知道，MVC 中的控制器，如果参数中带了强类型的参数，则 MVC 引擎会自动前台 post 过来的 JSON 对象转换为该强类型。如，我们后台是这样的（即，在参数中声明了强类型）：

public class xTemp
{
    public string XId { get; set; }
    public string XName { get; set; }
}

public JsonResult xTest(xTemp SomeData)
{
    。。。
    return this.Json(easyUiPages, JsonRequestBehavior.AllowGet);
}

以及前台是这样的：

var SomeData = {
    "xId": "xxx",
    "xName": "zzz"
};
$.ajax({
    type: "post",
    data: SomeData,
    url: "@ViewBag.Domain/home/xTest",
    success: function (data) {
        ;
    }
});

则我们的后台一定会解析得到这个对象。但是，如果我们将控制器中的 SomeData的声明换成了 object 或者 dynamic，则我们什么也不会得到。所以，如果不想创建新的类型，则有集中做法：

1：一一获得对象的属性

直接传递或再创建 dynamic 对象，然后将其传递到 bll 或者 dal 层进行处理；一般要处理的对象属性少于3个，可这样处理。

2：或者，还是老老实实创建实体吧

传统我们至少有三种选择：创建 ViewModel 或 领域实体 或 数据实体。

2.1ViewModel 是指在 UI 层的实体，默认在 UI 层创建一个 ViewModel 的文件夹进行放置，这些实体不发散到其它层。当然，如果一定要发散到下层，可以传递 dynamic；

2.2 领域实体，则指在业务逻辑层的实体，或者我们也称之为业务实体。业务实体和业务类并行放置一起，上层（如 UI 层）可访问，下层不可访问；

2.3 数据实体，则指最底层的，连 DAL 层都能访问的实体，一般用于映射数据库表（联表则使用导航属性，如 EntityFramework 等使用的），但一些通用的实体类，也可放置在此层。备注：也可以将领域实体作为数据实体；

在一些小型应用中，往往 ViewModel 、领域实体、数据实体，统一归并到实体层。总之，实体层的创建和放置必须非常明确，随意创建并且随意放置的实体类，会导致代码膨胀并给重构带来灾难。

如果我们发现数据实体已经不够用，这里建议的路线图是：

1：修改数据实体或创建新的数据实体；

2：如果数据实体不能动，或不想动，则创建 ViewModel；

3：如果发现业务类需要用到该实体，则把该 ViewModel 重构为 领域实体；

4：如果发现该实体要传递到 DAL 层，那么我们有四种选择，

4.1 手动转为数据实体；

4.2 回到第一步，将实体重构为数据实体；

4.3 使用 dynamic 传递到 Dal 层；

4.4 将属性作为参数传递；

创建多余的实体的做法，可以看到我们啰啰嗦嗦讲了这么多，如果你已经觉得很烦了，或者觉得自己根本掌握不了这个度，那么我们的终极做法是下面的这个做法。

3：接受 JSON 字符串，反序列化为 dynamic

上面我们说到：将控制器中的 SomeData的声明换成了 object 或者 dynamic，则我们什么也不会得到。但是，我们可以这么做，

前台的 data: SomeData ，换为：

data: "someData=" + JSON.stringify(SomeData)

注意，因为我们这里实际传递的是字符串，所以不能声明：

contentType: "application/json; charset=utf-8",

后台则为：

[SessionFilter]
public JsonResult XTest(string someData)
{
    var jsSerializer = new JavaScriptSerializer();
    var model = jsSerializer.Deserialize(somData, typeof(dynamic)) as dynamic;
    //如果是列表，则像如下处理
    //var models = jsSerializer.Deserialize(somData, typeof(List<dynamic>)) as List<dynamic>;

省略
    return this.Json(result, JsonRequestBehavior.DenyGet);
}

这是建议的、减少实体类型的行之有效的方法。

三：另一种思路：构建通用的实体类

该思路的中心思想就是：消灭所有的实体类，任何传统的实体无非就是：类型名+属性名+属性值，于是，我们就构建这样的一个通用实体类，类似：

[Serializable]
public sealed class DynamicDalObject : DynamicObject, IDictionary<string, object>
{
    public DynamicDalObject()
    {
        this._inner = new Dictionary<string, object>(StringComparer.OrdinalIgnoreCase);
    }

public DynamicDalObject(IEnumerable<KeyValuePair<string, object>> keyValuePairs) : this()
    {
        foreach (var keyValuePair in keyValuePairs)
        {
            this._inner.Add(keyValuePair);
        }
    }

……
}

然后，发散到 DAL 层，就可以进行这样的操作：

public static int Update(bool isOnline, int viewdCount, string Id)
{
    using (var manger = new DynamicDalSqlManager())
    {
        return
            manger.DataAccess.Update(
                new DynamicDalObject(
                    new[]
                        {
                            new KeyValuePair<string, object>("id", Id),
                            new KeyValuePair<string, object>("IsOnline", isOnline),
                            new KeyValuePair<string, object>("ViewdCount", viewdCount),
                        }),
                "EL_Course.CourseHistory",
                new[] { "id" });
    }
}

优点：

1：只要不想用实体类，就用它解决；

2：可构建通用的 Dal，即，DAl 只要一个也就够了；

缺点：

1：失去了面向对象结构，实际上变成了面向 SQL 编码；

2：不停的拆箱、装箱；

这种通用实体类的做法，在一些业务相对单一，可尝试使用，能带来短平快的效果。

四：总结

总之，应充分利用 匿名类型 和 dynamic 类型来减少无必要的或者模棱两可的实体类的创建，最后，再明确一下建议的架构思路：

1：首先我们有数据实体层，该实体层可拓展；

2：若现有实体不能满足需要，则从 DAL 到 UI，可使用匿名类型；

3：若现有实体不能满足需要，则从 客户端 到 控制器，可 JSON 字符串（非对象），在控制器中反序列化为 dynamic 类型；

4：最后，如发现某个业务方法被多个场景使用，可再将其 dynamic 对象重构成一个 数据实体（优先） 或 领域实体。为什么数据实体优先呢，因为从业务层传递到 DAL 层，我们可以直接传递该强类型对象。

5：在领域模型中，DTO 对象适用于本建议。