将结构不良的信息传递给WCF方法。最佳实践

Question

我有一个旧的Reporting Engine类，它使用单个方法CreateReport(Guid reportId, ReportParams params);

负责50多个报告

报告需要12种不同的参数类型（Guid，int，bool，枚举）及其组合。例如：

• 报告＃1：无需参数
• 报告＃2：2布尔（用户填写的复选框）
• 报告＃3：Guid（personId）＆amp;整数（开始年份）
• 报告＃4：Guid（personId）＆amp; PersonType（枚举）

ReportParams是一个具有12个以上属性的类，在调用方法之前填充了数组。但是大部分都没有通过电话使用。 Report Engine类检查是否填充了适当的属性并使用强类型信息访问。

在我决定使报告引擎WCF友好之前，一切都很好。每次添加新参数类型时，我都必须重建服务器，更新代理（导致客户端重新安装），并确保在WCF友好版本和报告引擎版本之间正确转换ReportParam结构。

我想知道如何最小化所有这些转换，检查，客户端重新安装e.t.c.可能我会将ReportParam重构为XML文档吗？它将使代理稳定，ReportParams wcf友好，但我将不得不在Report Engine类中重构强类型信息访问。

你会建议什么？

Answer 1

您是否控制WCF通信的两端？

在那种情况下：

• 将您的服务合同（接口）和数据合同放入类库程序集
• 在服务器和客户端之间共享该程序集
• 在客户端上，使用ChannelFactory<T>和factory.CreateChannel()手动创建通信渠道

在此设置中，您将对数据协定进行一次更改，重建您的服务和客户端，然后您就完成了。没有杂乱的“更新服务参考”等。

Answer 2

我对你的问题并不十分清楚，但在我对代表的永不满足的追求中，我不能阻止这一点。

首先，我肯定建议在报告代码和WCF代码之间放置一个“防火墙”。您应该将您的WCF代码视为facade，尽可能将其与报告的更改隔离开来。如果您的报告引擎需要更改，您可以重写服务器代码而不会弄乱客户端代码。

接下来的事情是，我已经摆脱了通过一次通话一般可以提供X个报告的想法。您应该将每个报告公开为一个单独的调用，每个调用都有一个签名，该签名包含报告所需的确切数量和类型的参数。

但是，您问，报告发生变化时会发生什么，或者必须添加新报告？您不能（即，在任何情况下都不应该）版本接口，并且您的服务合同是一个接口。因此，随着报告的更改，您必须将OLD报告方法标记为已过时。将更新的方法（以及新报告的方法）添加到将与旧服务合同一起提供的新服务合同中。如果人们尝试使用旧的报表方法，请尝试到期（对未提供的参数应用合理的默认值）或抛出异常。如果报告急剧变化到需要重新安装客户端的位置，请考虑将更新的报告添加为新报告。

添加更新的报告和/或新报告变得很简单，只需在服务器上删除新的二进制文件并更改.config文件即可。