减少到处衍生的实体类

时间：2014-06-18 08:43:40 阅读：306 评论：0 收藏：0 [点我收藏+]

标签：des class blog java http tar

这里的实体类更倾向于数据传输对象（既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" });
    }
}