wcf服务和asp.net表示层

您应该在服务和asp.net项目之间共享类对象库。这就像是整个项目的"中间件"。这将避免不必要的重复。基本上，只需将所有业务对象移到不同的项目中，并将其包含在wcf和asp.net解决方案中。

不是。当您通过visual studio使用添加服务引用将引用添加到web服务时，您将获得web服务中使用的每个对象的代理类

服务的标准做法是返回DTO而不是业务对象：在表示层中使用业务对象会将其与业务逻辑紧密耦合，大多数时候您不希望这种耦合。还要记住，您在网络上发送的所有内容都应该是可序列化的，您的业务对象可能是可串行的，也可能不是可串行的。

所以我想说，是的，你很可能想用DTO创建一个不同的库，并将其中的类用作数据契约。重复并不是一个真正的问题，因为它保证了合同的一定稳定性，并且可以使用AutoMapper等工具将业务对象映射到DTO。

让我们考虑一下在表示层（ASP.NET）和服务层之间共享公共业务类库的方法的优点和缺点。

优点：

• 易于实现：只需将现有项目连接到asp.net，将类标记为可序列化，就完成了
• 非冗余：您有一个类来表示一个概念

缺点：

• 您的类可能不可序列化
• 在不经过服务的情况下，很容易"滑动"并使用不应该直接在表示层中使用的业务类
• 紧密耦合：更改业务类，服务层和表示层都可能中断
• 为什么我们要再次使用服务

将此与创建DTO库进行比较：

优点：

• 接口（数据契约）定义得很好：这个库中的所有东西都是一个通信对象
• 序列化没有问题
• 表示和服务之间的松散耦合：在数据契约抽象的帮助下，业务逻辑的变化最多反映到DTO映射级别

缺点：

• 您需要将对象映射到DTO（认为AutoMapper在这方面非常有用）
• Dmitriy列举了重复，尽管不必要是主观的：我想我已经向你展示了为什么需要它。此外，你不应该害怕在应用程序的不同部分引入对同一概念的不同看法：我还没有找到一个完全适合非平凡程序中每个用例的模型