c# - wcf 服务和 asp .net 表示层

Question

我有负责数据库交互和业务逻辑的 wcf 服务。它还有业务对象的类库。我希望 wcf 服务返回对象列表。我是否必须为我的 asp .net 项目（正在使用服务）创建另一个业务对象类库，以便 asp .net 项目可以理解对象类型？

Answer 1

You should share the class object library between the service and the asp.net project. That would be like 'middleware' for your whole project. That would avoid unnecessary duplication. Basically, just move all business objects to a different project and include it into both wcf and asp.net solutions.

Answer 2

Not really. When you will add the reference to web service using Add Service Reference via visual studio, you will get proxy classes for every object to be used in the web service

Answer 3

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

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

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

优点：

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

缺点：

• 您的类可能无法序列化
• 很容易“滑倒”并使用不应该直接在表示层中使用的业务类，而无需通过服务
• 紧密耦合：更改业务类，服务和表示层都可能中断
• 为什么我们再次使用服务？

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

优点：

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

缺点：

• 您需要将您的对象映射到 DTO（认为 AutoMapper 对此非常有帮助）
• Dmitriy 引用了重复，虽然不必要是主观的：我想我向你展示了为什么需要它。此外，你不应该害怕在应用程序的不同部分引入对同一概念的不同视图：我还没有找到一个模型可以完美地适应非平凡程序中的每个用例。