.net 我的服务设计糟糕吗？

我正在开发一个遵循MSDN的WCF服务。也就是说，我遵循了那篇文章中的大部分指导原则，并且我的数据和服务合同在服务层的单独程序集中。问题是，该服务在很大程度上基于底层数据库及其客户机应用程序之间的事务，因此，我在数据库中几乎每个实体都有一个类（数据契约）。因为服务层不应该直接访问DAL，所以我在业务层中有一组方法，它接收传递给服务的参数，从服务层实例化相应的实体，并与DAL（企业库的DAAB）通信以进行CRUD操作。然而，我觉得这些CRUD操作属于服务层中的每个类，但是将它们放在那里会使服务层直接调用DAL。。。我的问题是：

1） 每个数据库实体有一个数据契约是一种糟糕的做法吗

2） CRUD操作是否应该直接放在服务层上（从而导致服务层直接依赖DAL程序集）--或--

---

3） 相反，我应该为业务层中的每个契约创建一个包装类，并将CRUD操作放在那里，使用（可能）接口方法在层之间通信吗？

严格要求每个数据库实体有一个数据契约将是人为的限制。在一个简单的应用程序中，您有数据库实体，并且所有的交互都是这些实体上的单个CRUD操作，它可能可以正常运行。但在更复杂的应用程序中，很常见的情况是需要跨多个数据库实体连接调用，甚至需要在一个批处理调用（批处理或存储过程）中更新多个实体

我可能不会直接从服务层访问DAL。拥有一个业务层允许您以最少的搅动完全改变数据持久化的方式，还允许您直接对业务层进行单元测试，而无需启动服务

接口可以帮助解耦，但这不是一个严格的要求。业务层可以使用契约定义其数据需求，您可以向业务层提供一个数据源对象（dal），作为实现接口的委托—它将层解耦。这允许您编写业务层，让它定义所需的数据，然后让DAL实现。这与创建CRUD对象和以另一种方式设计层相反。关注业务问题，定义满足业务需要的数据，然后编写一个DAL，以尽可能快的速度实现这些需求。从头开始设计

因此，总而言之，我将重点构建一个向客户机公开逻辑操作的服务，该服务具有一个实施规则的业务层和一个能够满足这些业务层需求的数据层。在设计这些层时，要关注性能，尽量减少往返，缩短连接和事务范围时间