wcf 服务和asp .net 表示层

Question

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

Answer 1

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

Answer 2

并不真地。 当您通过 visual studio 使用添加服务引用添加对 web 服务的引用时，您将获得每个 object 的代理类，以在 web 服务中使用

Answer 3

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

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

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

优点：

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

缺点：

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

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

优点：

• 接口（数据合同）定义明确：这个库中的所有内容都是一个通信 object
• 序列化没有问题
• 表现与服务松耦合：借助数据契约的抽象，业务逻辑的变化最多反映到DTO映射层

缺点：

• 你需要 map 你的对象到 DTO（认为 AutoMapper 对此很有帮助）
• Dmitriy 引用了重复，虽然不必要是主观的：我想我已经向你展示了为什么需要它。 此外，你不应该害怕在你的应用程序的不同部分引入相同概念的不同视图：我还没有找到一个 model 完美适合重要程序中的每个用例。