在使用Entity Framework 实体框架的时候，我们大多数时候操作的都是实体模型Entity，这个和数据库操作上下文结合，可以利用LINQ等各种方便手段，实现起来非常方便，一切看起来很美好。但是如果考虑使用WCF的时候，可能就会碰到很多相关的陷阱或者错误了。因为实体模型Entity的对象可能包括了其他实体的引用，在WCF里面就无法进行序列化，出现错误；而且基于WCF的时候，可能无法有效利用Express表达式，无法直接使用LINQ等问题都一股脑出现了。本文基于上面的种种问题，阐述了我的整个Entity Framework 实体框架的解决思路，并且在其中引入了数据传输模型DTO来解决问题，本文主要介绍数据传输模型DTO和实体模型Entity的分离与联合，从而实现我们通畅、高效的WCF应用框架。

1、实体模型Entity无法在WCF中序列化

例如，我们定义的Entity Framework 实体类里面包含了其他对象的引用，例如有一个Role对象，有和其他表的关联关系的，默认使用传统方式，在实体类里面添加[DataContract]方式。

/// 
/// 角色
/// 
[DataContract(IsReference = true)]
public class Role
{ 
    /// 
    /// 默认构造函数（需要初始化属性的在此处理）
    /// 
    public Role()
    {
        this.ID= System.Guid.NewGuid().ToString();

        //Children = new HashSet();
        //Users = new HashSet();
     }

    #region Property Members

    [DataMember]
    public virtual string ID { get; set; }

    /// 
    /// 角色名称
    /// 
    [DataMember]
    public virtual string Name { get; set; }

    /// 
    /// 父ID
    /// 
    [DataMember]
    public virtual string ParentID { get; set; }

    [DataMember]
    public virtual ICollection Children { get; set; }

    [DataMember]
    public virtual Role Parent { get; set; }

    [DataMember]
    public virtual ICollection Users { get; set; }

    #endregion

}

在WCF服务接口里面使用代码如下所示。

public class Service1 : IService1
{
    public List GetAllRoles()
    {
        return IFactory.Instance().GetAll().ToList();
    }

     .........

那么我们在WCF里面使用的时候，会得到下面的提示。
接收对 http://localhost:11229/Service1.svc 的 HTTP 响应时发生错误。这可能是由于服务终结点绑定未使用 HTTP 协议造成的。这还可能是由于服务器中止了 HTTP 请求上下文(可能由于服务关闭)所致。有关详细信息，请参见服务器日志。
默认情况下，Entity Framework为了支持它的一些高级特性(延迟加载等)，默认将自动生成代理类是设置为true。如果我们需要禁止自动生成代理类，那么可以在数据库操作上下文DbContext里面进行处理设置。

Configuration.ProxyCreationEnabled = false;

如果设置为false,那么WCF服务可以工作正常，但是实体类对象里面的其他对象集合则为空了，也就是WCF无法返回这些引用的内容。
同时，在Entity Framework框架里面，这种把实体类贯穿各个层里面，也是一种不推荐的做法，由于WCF里面传输的数据都是序列号过的数据，也无法像本地一样利用LINQ来实现数据的处理操作的。
那么我们应该如何构建基于WCF引用的Entity Framework实体框架呢？

2、数据传输对象DTO的引入

前面介绍了直接利用Entity Framework实体类对象的弊端，并且如果是一路到底都使用这个实体类，里面的很多对象引用都是空的，对我们在界面层使用不便，而且也可能引发了很多WCF框架里面的一些相关问题。
我们根据上面的问题，引入了一个DTO（数据传输对象）的东西。
数据传输对象（DTO）是没有行为的POCO对象，它的目的只是为了对领域对象进行数据封装，实现层与层之间的数据传递，界面表现层与应用层之间是通过数据传输对象（DTO）进行交互的。数据传输对象DTO本身并不是业务对象，数据传输对象是根据UI的需求进行设计的。
这个对象和具体数据存储的实体类是独立的，它可以说是实体类的一个映射体，名称可以和实体类不同，属性数量也可以实体类不一致。那么既然在实体对象层外引入了另外一个DTO对象层，那么相互转换肯定是避免不了的了，我们为了避免手工的映射方式，引入了另外一个强大的自动化映射的工具AutoMapper，来帮助我们快速、高效、智能的实现两个层对象的映射处理。

AutoMapper的使用比较简单，一般如果对象属性一直，他们会实现属性自动映射了，如下所示。

Mapper.CreateMap();

如果两者的属性名称不一致，那么可以通过ForMember方式指定，类似下面代码所示。

AutoMapper.Mapper.CreateMap() 
  .ForMember(dto => dto.PostId, opt => opt.MapFrom(entity => entity.ID));

AutoMapper也可以把映射信息写到一个类里面，然后统一进行加载。

Mapper.Initialize(cfg => { cfg.AddProfile();});

那么基于上面的图示模式，由于我们采用代码生成工具自动生成的DTO和Entity，他们属性名称是保持一致的，那么我们只需要在应用层对它们两者对象进行相互映射就可以了。

public class RoleService : BaseLocalService, IRoleService
{               
    private IRoleBLL bll = null;

    public RoleService() : base(IFactory.Instance())
    {
        bll = baseBLL as IRoleBLL;

        //DTO和Entity模型的相互映射
        Mapper.CreateMap();
        Mapper.CreateMap();
    }
}

基于这个内部对接的映射关系，我们就可以在Facade接口层提供统一的DTO对象服务，而业务逻辑层（也就是利用Entity Framework 实体框架的处理成）则依旧使用它的Entity对象来传递。下面我提供几个封装好的基类接口供了解DTO和Entity的相互衔接处理。

1）传入DTO对象，并转换为Entity对象，使用EF对象插入。

/// 
/// 插入指定对象到数据库中
/// 
/// 指定的对象
/// 执行成功返回true，否则为false
public virtual bool Insert(DTO dto)
{
    Entity t = dto.MapTo();
    return baseBLL.Insert(t);
}

2）根据条件从EF框架中获取Entity对象，并转换后返回DTO对象

/// 
/// 查询数据库,返回指定ID的对象
/// 
/// ID主键的值
/// 存在则返回指定的对象,否则返回Null
public virtual DTO FindByID(object id)
{
    Entity t = baseBLL.FindByID(id);
    return t.MapTo();
}

3）根据条件从EF框架中获取Entity集合对象，并转换为DTO列表对象

/// 
/// 返回数据库所有的对象集合
/// 
/// 
public virtual ICollection GetAll()
{
    ICollection tList = baseBLL.GetAll();
    return tList.MapToList();
}

3、Entity Framework 实体框架结构

基于方便管理的目的，每个模块都可以采用一种固定分层的方式来组织模块的业务内容，每个模块都是以麻雀虽小、五脏俱全的方针实施。实例模块的整个业务逻辑层的项目结构如下所示。

如果考虑使用WCF，那么整体的结构和我之前的混合框架差不多，各个模块的职责基本没什么变化，不过由原先在DAL层分开的各个实现层，变化为各个数据库的Mapping层了，而模型增加了DTO，具体项目结构如下所示。

具体的项目说明如下所示：
EFRelationship
系统的业务模块及接口、数据库访问模块及接口、DTO对象、实体类对象、各种数据库映射Mapping类等相关内容。该模块内容紧密结合Database2Sharp强大代码生成工具生成的代码、各层高度抽象继承及使用泛型支持多数据库。

EFRelationship.WCFLibrary
系统的WCF服务的业务逻辑模块，该模块通过引用文件方式，把业务管理逻辑放在一起，方便WCF服务部署及调用。

EFRelationshipService
框架WCF服务模块，包括基础服务模块BaseWcf和业务服务模块，他们为了方便，分开管理发布。

EFRelationship.Caller
定义了具体业务模块实现的Façade应用接口层，并对Winform调用方式和WCF调用方式进行包装的项目。

具体我们以一个会员系统设计为例，它的程序集关系如下所示。

我们来看看整个架构的设计效果如下所示。

其中业务逻辑层模块（以及其它应用层）我们提供了很多基于实体框架的公用类库（WHC.Framework.EF)，其中的继承关系我们将它放大，了解其中的继承细节关系，效果如下所示。

上图很好的概述了我的EF实体框架的设计思路，这些层最终还是通过代码生成工具Database2Sharp进行一体化的生成，以提高快速生产的目的，并且统一所有的命名规则。后面有机会再写一篇随笔介绍代码生成的逻辑部分。
上图左边突出的两个工厂类，一个IFactory是基于本地直连方式，也就是直接使用EF框架的对象进行处理；一个CallerFactory是基于Facade层实现的接口，根据配置指向WCF数据服务对象，或者直连对象进行数据的操作处理。