在使用Entity Framework 实体框架的时候，我们大多数时候操作的都是实体模型Entity，这个和数据库操作上下文结合，可以利用LINQ等各种方便手段，实现起来非常方便，一切看起来很美好。但是如果考虑使用WCF的时候，可能就会碰到很多相关的陷阱或者错误了。因为实体模型Entity的对象可能包括了其他实体的引用，在WCF里面就无法进行序列化，出现错误；而且基于WCF的时候，可能无法有效利用Express表达式，无法直接使用LINQ等问题都一股脑出现了。本文基于上面的种种问题，阐述了我的整个Entity Framework 实体框架的解决思路，并且在其中引入了数据传输模型DTO来解决问题，本文主要介绍数据传输模型DTO和实体模型Entity的分离与联合，从而实现我们通畅、高效的WCF应用框架。
1、实体模型Entity无法在WCF中序列化
例如，我们定义的Entity Framework 实体类里面包含了其他对象的引用，例如有一个Role对象，有和其他表的关联关系的，默认使用传统方式，在实体类里面添加[DataContract]方式。
/// <summary>
/// 角色
/// </summary>
[DataContract(IsReference = true)]
public class Role
{
/// <summary>
/// 默认构造函数（需要初始化属性的在此处理）
/// </summary>
public Role()
{
this.ID= System.Guid.NewGuid().ToString();
//Children = new HashSet<Role>();
//Users = new HashSet<User>();
}
#region Property Members
[DataMember]
public virtual string ID { get; set; }
/// <summary>
/// 角色名称
/// </summary>
[DataMember]
public virtual string Name { get; set; }
/// <summary>
/// 父ID
/// </summary>
[DataMember]
public virtual string ParentID { get; set; }
[DataMember]
public virtual ICollection<Role> Children { get; set; }
[DataMember]
public virtual Role Parent { get; set; }
[DataMember]
public virtual ICollection<User> Users { get; set; }
#endregion
}
在WCF服务接口里面使用代码如下所示。
public class Service1 : IService1
{
public List<Role> GetAllRoles()
{
return IFactory.Instance<IRoleBLL>().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<RoleInfo, Role>();
如果两者的属性名称不一致，那么可以通过ForMember方式指定，类似下面代码所示。
AutoMapper.Mapper.CreateMap<BlogEntry, BlogPostDto>()
.ForMember(dto => dto.PostId, opt => opt.MapFrom(entity => entity.ID));
AutoMapper也可以把映射信息写到一个类里面，然后统一进行加载。
Mapper.Initialize(cfg => { cfg.AddProfile<OrganizationProfile>();});
那么基于上面的图示模式，由于我们采用代码生成工具自动生成的DTO和Entity，他们属性名称是保持一致的，那么我们只需要在应用层对它们两者对象进行相互映射就可以了。
public class RoleService : BaseLocalService<RoleInfo, Role>, IRoleService
{
private IRoleBLL bll = null;
public RoleService() : base(IFactory.Instance<IRoleBLL>())
{
bll = baseBLL as IRoleBLL;
//DTO和Entity模型的相互映射
Mapper.CreateMap<RoleInfo, Role>();
Mapper.CreateMap<Role, RoleInfo>();
}
}
基于这个内部对接的映射关系，我们就可以在Facade接口层提供统一的DTO对象服务，而业务逻辑层（也就是利用Entity Framework 实体框架的处理成）则依旧使用它的Entity对象来传递。下面我提供几个封装好的基类接口供了解DTO和Entity的相互衔接处理。
1）传入DTO对象，并转换为Entity对象，使用EF对象插入。
/// <summary>
/// 插入指定对象到数据库中
/// </summary>
/// <param name="dto">指定的对象</param>
/// <returns>执行成功返回<c>true</c>，否则为<c>false</c></returns>
public virtual bool Insert(DTO dto)
{
Entity t = dto.MapTo<Entity>();
return baseBLL.Insert(t);
}
2）根据条件从EF框架中获取Entity对象，并转换后返回DTO对象
/// <summary>
/// 查询数据库,返回指定ID的对象
/// </summary>
/// <param name="id">ID主键的值</param>
/// <returns>存在则返回指定的对象,否则返回Null</returns>
public virtual DTO FindByID(object id)
{
Entity t = baseBLL.FindByID(id);
return t.MapTo<DTO>();
}
3）根据条件从EF框架中获取Entity集合对象，并转换为DTO列表对象
/// <summary>
/// 返回数据库所有的对象集合
/// </summary>
/// <returns></returns>
public virtual ICollection<DTO> GetAll()
{
ICollection<Entity> tList = baseBLL.GetAll();
return tList.MapToList<Entity, DTO>();
}
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数据服务对象，或者直连对象进行数据的操作处理。
