wcf服务和asp.net表示层

Question

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

Answer 1

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

Answer 2

不是真的。当您通过visual studio使用“添加服务引用”添加对Web服务的引用时，您将获得要在Web服务中使用的每个对象的代理类

Answer 3

使用服务的标准做法是返回DTO而不是业务对象：在表示层中使用业务对象将它与业务逻辑紧密结合，并且大多数时候您不想要这种耦合。另外请记住，您在线路上发送的所有内容都应该是可序列化的，并且您的业务对象可能是也可能不是可序列化的。

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

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

优点：

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

缺点：

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

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

优点：

• 界面（数据合同）定义明确：此库中的所有内容都是通信对象
• 序列化没问题
• 表示和服务之间的松散耦合：在数据合同抽象的帮助下，业务逻辑的变化最多反映到DTO映射级别

缺点：

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