我正在开发WCF服务，它是更大系统的一部分。该服务将提供一些业务逻辑，并将通过实体框架（使用模型优先）连接到数据库。我看到有许多不同的方式将实体框架与WCF服务（基本实体，DTO，自我跟踪实体，POCO等）联系起来。我的基本要求：
由于我的要求，我的愿景是如何构建的最接近（我认为它是最接近DTO的方法）： http://www.codeproject.com/Articles/127395/Implementing-a-WCF-Service-with-Entity-Framework
但我认为数据访问层应该与服务的逻辑分开（2个程序集：项目，命名空间，dll，但作为一个应用程序工作）。在这种情况下，我有一些问题应该是这两个层中的每一个应该做什么：是否应该在服务中完成所有逻辑并且DAL将仅用作CRUD？或者Service应该只负责明确的业务逻辑，而整个数据库逻辑（使用linq的特定查询）将在DAL中完成（DAL公开的许多更具体的方法）？同样重要的是，应该将这些对象发送到这两层：数据合同，实体还是其他模型？
在我提到的情况下，我的方法是否正常？
答案 0 :(得分：1)
在SOA之前，N层或3层体系结构通常具有专用的业务层。如果您对关注点分离感到强烈（或者如果您认为可能会从非服务使用者那里重用业务功能），为什么不将业务逻辑从服务层移出？ （但不要将业务逻辑放在DAL中）
但是，如果您的服务层确实提供数据查询服务以及事务性服务，那么这些服务不需要业务层 - 请在此处查看CQRS类型设计模式。
如果您需要控制实体的XML格式（Names，xmlns等），您可能需要构建自定义WCF DataContract或MessageContract实体。 但是，如果您不关心数据在整个线路中的样子，您可以简单地使用EF实体类（只要它们不是上下文绑定的 - 即如果使用带有EF的POCO）。如果您没有将POCO归因于DataContract等，则DataContractSerializer的默认行为是序列化公共属性。
所以你最终可以使用以下装配'层'（自下而上）