我正在开发一个遵循MSDN service archetype的WCF服务。也就是说，我遵循该文章中的大部分指导原则，并且我将数据和服务合同放在服务层的单独程序集中。问题是这个服务很大程度上基于底层数据库和它的客户端应用程序之间的事务，所以我在数据库中每个实体几乎有一个类（数据协定）。由于服务层不应该直接访问DAL，因此我在业务层中有一组方法接收传递给服务的参数，从服务层实例化相应的实体并与DAL（企业库的DAAB）通信以进行CRUD操作。但是，我觉得这些CRUD操作属于服务层中的每个类，但是将它们放在那里会使服务层直接调用DAL ...我的问题是：
1）每个数据库实体有一个数据契约是不好的做法吗？
2）CRUD操作是否应直接放在服务层上（从而导致服务层直接依赖于DAL组件）？ --or -
3）相反，我应该为业务层中的每个合同创建一个包装器类，并将CRUD操作放在那里，使用（可能）接口方法在层之间进行通信吗？ / p>
答案 0 :(得分：2)
每个数据库实体严格要求一个数据合同将是一个人为的限制。在一个简单的应用程序中，您拥有数据库实体，并且所有交互都是对这些实体的单独CRUD操作，它可以保持正常。但是在一个更复杂的应用程序中，通常需要连接多个数据库实体，甚至在一个批处理调用（批处理或sproc）中更新许多实体。
我可能不会直接从服务层访问DAL。拥有业务层允许您以最小的流失率完全更改数据的持久性，并允许您直接对业务层进行单元测试，而无需启动服务。
接口可以帮助解耦，但这不是一个严格的要求。业务层可以使用契约定义它的数据需求，您可以将业务层的数据源对象（dal）作为实现接口的委托提供 - 它将层分离。这允许您编写业务层并让它定义它需要的数据，然后使用DAL实现。这与创建CRUD对象和在堆栈中以另一方向设计图层相反。关注业务问题，定义满足业务需要的数据，然后编写一个尽可能快地实现这些需求的DAL。设计堆栈。
因此，总而言之，我将专注于构建向客户端公开逻辑操作的服务，其中包含强制执行规则的业务层和可满足这些业务层要求的数据层。在设计这些层时，请注重性能，尽量减少往返，并缩小连接和事务处理范围的时间。