WCF服务和实体框架n层应用程序问题

Question

我正在开发WCF服务，它是较大系统的一部分。该服务将提供一些业务逻辑，并将通过实体框架（使用模型优先）连接到数据库。我发现有许多不同的方式与WCF服务（基本实体，DTO，自我跟踪实体，POCO等）联合实体框架。我的基本要求：

• 的服务是瘦客户机（和其他服务）所建，大部分的逻辑是在其一侧，所以它不是任何CRUD应用程序（WCF数据服务是不适合我）
• 不同的客户需要不同的粒度级别的数据，所以在数据库中的同一实体会有不同的数据合同

由于我的要求我的眼光应该如何构建最接近（我认为这是最接近到DTO方法）： http://www.codeproject.com/Articles/127395/Implementing-a-WCF-Service-with-Entity-Framework

但我认为数据访问层应该与服务的逻辑（2个程序集：项目，名称空间，DLL，但作为一个应用程序工作）分开。在这种情况下，我会遇到一些问题：这两层应该分别做什么：应该在服务中完成所有的逻辑，并且将DAL用作CRUD？或者应该服务只负责明确的业务逻辑，而整个数据库逻辑（使用linq的具体查询）将在DAL（通过DAL公开的更多特定方法）中完成？还有什么是重要的哪些对象应该发送这些2层：数据契约，实体或附加模型？

在上述情况下，我的方法可以吗？

Answer 1

在SOA之前，N层或3层架构一般都有专门的业务层。如果您对问题的分离感觉足够强烈（或者如果您认为可能会从非服务用户那里重用您的业务功能），为什么不将业务逻辑移出服务层？ （但不要把业务逻辑在DAL）

但是，如果你的服务层确实提供数据查询服务，以及交易者，则不需要这些服务的业务层 - 看看CQRS在这里输入设计模式。

如果您需要控制实体的XML格式（名称，xmlns等），您可能需要构建自定义的WCF DataContract或MessageContract实体。然而，如果你不关心跨越线路的数据是什么样子的，你可以简单地使用EF实体类（只要它们不是上下文绑定的 - 即，如果在EF上使用POCO）。如果您没有将POCO与DataContract等属性相关联，则DataContractSerializer的默认行为是序列化公共属性。

所以，你可以风与以下汇编 '层'（自下而上）的EF

• DAL实体（无论是ObjectContext的约束或POCO）
• EF DAL
• 业务层（事务服务方法只 - 绕过查询）
• 可能彼此独立的WCF实体，在那里你映射你的POCO/DAL BE对DataContract/MessageContract
• WCF服务层