将结构不良的信息传递给 WCF 方法。最佳实践
我有遗留的报告引擎类，它使用单一方法 CreateReport(Guid reportId, ReportParams params); 负责 50 多个报告；
报告需要 12 个以上不同的参数类型（Guid、int、bool、枚举）以及它们的组合。例如：
- 报告#1：不需要参数
- 报告#2：2 个布尔值（复选框由用户填充）
- 报告#3：Guid (personId) & 2 个 布尔值（复选框由用户填充）整数（开始年份）
- 报告 #4：Guid (personId) & PersonType（枚举）
ReportParams 是一个具有 12 个以上属性和数组的类，这些属性和数组在调用方法之前填充。但其中大多数在每次调用时都未使用。报表引擎类检查是否填充了适当的属性并使用强类型信息访问。
一切都很好，直到我决定让报告引擎 WCF 友好。每次添加新参数类型时，我都必须重建服务器、更新代理（这会导致客户端重新安装），并确保 ReportParam 结构在 WCF 友好版本和报表引擎版本之间正确转换。
我想知道如何最大程度地减少所有这些转换、检查、客户端重新安装等，我可以将 ReportParam 重构为 XML 文档吗？它将使代理稳定，ReportParams wcf 友好，但我必须重构报表引擎类中的强类型信息访问。
你会建议什么？
I have legacy Reporting Engine class that is responsible for 50+ reports with a single method CreateReport(Guid reportId, ReportParams params);
Reports require 12+ of different parameter types (Guid, int, bool, enumerations) and their combination. For example:
- Report #1: No parameters are required
- Report #2: 2 Booleans (checkboxes populate by user)
- Report #3: Guid (personId) & integer (year to start with)
- Report #4: Guid (personId) & PersonType (enumeration)
ReportParams is a class with 12+ properties and arrays that are populated before calling the method. But most of them are unused per call. Report Engine class checks that appropriate properties are populated and uses strong type information access.
Everything was ok until I decided to make reporting engine WCF friendly. Every time I add new parameter type I have to rebuild server, update proxy (that leads to clients reinstall), and make sure that ReportParam structure is converted correctly between WCF-friendly version and Reporting Engine version.
I wonder how to minimize all this conversions, checks, client reinstallations e.t.c. May be I shall refactor ReportParam to XML document? It will make proxy stable, ReportParams wcf friendly, but I'll have to refactor strong type information access in the Report Engine class.
What will you suggest?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
你控制WCF通信的两端吗？
在这种情况下：
ChannelFactory和factory.CreateChannel( )手动创建通信通道在此设置中，您对数据协定进行一次更改，重建服务和客户端，然后就完成了。没有混乱的“更新服务参考”等。
Do you control both ends of the WCF communication??
In that case:
ChannelFactory<T>andfactory.CreateChannel()to manually create the communication channelIn this setup, you make the change to the data contract once, rebuild your service and client, and you're done. No messy "Update Service Reference" etc.
我不太清楚你的问题，但让我不要停止对代表的永不满足的追求。
首先，我绝对建议在报告代码和 WCF 代码之间放置一个“防火墙”。您应该将 WCF 代码视为外观，使其免受报告更改的影响可能的。如果您的报告引擎需要更改，您可以重写服务器代码，而不会弄乱客户端代码。
接下来，我将放弃这样的想法：您通常可以通过一次调用提供 X 份报告。您应该将每个报告公开为单独的调用，每个调用都有一个签名，该签名接受报告所需的参数的确切数量和类型。
但是，您会问，当报告更改或必须添加新报告时会发生什么？您不能（即在任何情况下都不应该）版本接口，并且您的服务契约是一个接口。因此，当报告发生变化时，您必须将 OLD 报告方法标记为已过时。将更新的方法（以及新报告的方法）添加到新的服务合同中，该合同将与旧的服务合同一起提供服务。如果人们尝试使用旧的报告方法，要么尝试做出适当的处理（对未提供的参数应用合理的默认值），要么抛出异常。如果报告发生巨大变化以至于需要重新安装客户端，请考虑将更新的报告添加为新报告。
添加更新的报告和/或新报告变得非常简单，只需在服务器上删除新的二进制文件并更改 .config 文件即可。
I'm not exactly clear on your issue, but let me not stop that in my insatiable quest for rep.
First thing, I'd definitely suggest placing a "firewall" between the reporting code and the WCF code. You should treat your WCF code as a facade, insulating it from changes to your reports as much as possible. If your reporting engine requires a change, you can rewrite the server code without messing with client code.
Next thing is that I'd get rid of the idea that you can generically serve up X number of reports via a single call. You should expose every report as a separate call, each having a signature which takes in the exact number and type of arguments the report requires.
But, you ask, what happens when the report changes, or a new report must be added? You cannot (i.e., should not under any circumstances) version interfaces, and your service contract IS an interface. Therefore, as reports change, you must mark the OLD report method as obsolete. Add the updated method (as well as methods for new reports) to a NEW service contract that will be served along side of the old one. If people try to use the old report method, either attempt to make due (apply reasonable defaults to those arguments not provided) or throw an exception. If a report changes drastically to the point where a client reinstall is required, consider adding the updated report as a new one.
Adding updated reports and/or new reports becomes a simple matter of dropping a new binary on the server and changing the .config file.