在我的 WPF 应用程序数据模型中,我有多个类表示通过 WCF 自托管服务与后端数据库交互的数据。
我的 WCF 服务中是否应该有多个数据协定或多个服务联系人或端点来表示这些多个 WPF 数据模型类?在这种情况下,构建 WCF 的正确(或者可能是唯一)方法是什么?
在我的 WPF 应用程序数据模型中,我有多个类表示通过 WCF 自托管服务与后端数据库交互的数据。
我的 WCF 服务中是否应该有多个数据协定或多个服务联系人或端点来表示这些多个 WPF 数据模型类?在这种情况下,构建 WCF 的正确(或者可能是唯一)方法是什么?
有一个称为接口隔离原则的设计建议,它基本上说明了 iDesign WCF 编码标准也说的内容:不要让你的接口(=你的服务合同)太大太笨重。
考虑一下:您有一个包含数百种方法的庞大服务合同,而某些第三方想要实现功能的子集,可能只有其中的两个或三个服务方法。如果你有一个巨大的服务合同,他们将不得不实现他们感兴趣的 3-4 服务方法,而所有其他的,他们将不得不存根一个假人 - 例如类似的throw new NotImplementedException();
东西。一般来说,这不是一个好主意。
所以基本原则应该是:尝试以这样一种方式对您的服务合同进行分组,如果其他人需要实现一个子集,他们很可能会找到一个包含他们需要的所有方法的单一服务合同,而不是其他任何东西。尝试按主题对服务合同进行分组,例如,如果您有 6 种搜索地址的方法,请将它们放在单独的服务合同中。如果您有 7 种其他方法来插入新地址、更新和删除现有地址——这可能应该是一个单独的服务合同(因为你可以想象有人只想搜索地址——而不是修改任何东西)。
所以我想没有真正的硬性规则什么是好的或不好的 - 尝试将您的服务分组为“逻辑连接”的方法组。当然,这不是一件容易的事!但值得努力思考其他人可能如何使用您的服务。
此外,如果您有一些较小的服务合同,如果您需要更改任何内容也容易得多。如果您需要在服务合同中引入重大更改,那么只有那些(希望少数)具有几种方法的特定服务合同的用户会受到影响。如果您总是不得不更改您庞大的 200 方法服务合同,您将始终影响到每个人——这可能不是一件好事!
在 WCF 术语中,数据协定是服务协定操作中使用的类。它被称为数据契约,因为它通常使用DataContractAttribute进行注释,以便成功识别和序列化(尽管从 .NET 3.5 SP1 DataContractSerializer开始使用 POCO 对象并且不再需要此属性)。因此,您可以拥有一个包含多个操作的单一服务合同,这些操作处理多个数据合同,所有这些数据合同都暴露在一个端点中。