在WCF中，具有多个操作契约更好还是只有一个具有多态数据契约的操作更好？
我想知道在 WCF 中使用多个操作合约更好，还是只有一个带有多态数据合约的操作合约更好。
让我给你一个小例子：
[OperationContract]
action1Answer action1(action1data a);
[OperationContract]
action2Answer action2(action2data a);
或者
[OperationContract]
actionAnswer action(actionContract a);
Action 合约将是一个抽象类，action1Contract 和 action2Contract 都将从它继承。动作契约将在其接口中指定 do() 成员函数，该函数又必须在子类中重载，
我个人认为第二种方法更有趣，因为它允许您很好地封装派生的 actionContract 中的数据和操作，从而更容易添加新操作。但这是我第一次使用 WCF，所以你可能更了解！
I was wondering if it was better in WCF to use multiple operation contracts or to have only one operation contract with a polymorphic data contract.
Let me give you a small example :
[OperationContract]
action1Answer action1(action1data a);
[OperationContract]
action2Answer action2(action2data a);
or
[OperationContract]
actionAnswer action(actionContract a);
Action contract would be an abstract class which both action1Contract and action2Contract will inherit from. The action contract would specify the do() member function in its interface which would have in turn to be overloaded in the child classes
Personnaly I find the second approach to be more intersting as it allow you to nicely encapsulate the data and the action in the derived actionContract and in turn makes it easier to add new actions. But It's the first time I'm using WCF so probably you know better!
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
这个问题接近 OO 多态性和 SOA 的圣战边缘，但我将提供我的两点意见：
当您考虑开发服务层时，服务的最终消费者应该清楚要传递什么内容以及会发生什么；方法2处理得不太好。 （此外，当使用 WCF 执行 SOAP，然后从其他 .NET 项目中的 wsdl 加载时，它无法正确标记抽象类，也不会传输接口。WSDL 似乎无法描述不可实例化的基类.)
不过，我必须承认，我认为使用 KnownTypeAttributes 的第二个过程很棒（正如我刚才看到的 marc_s 已经发布的那样）——当考虑到未知的未来需求时，我自己就使用了它。
This question borders on the edges of the Holy Wars of OO polymorphism and SOA, but I'll provide my two cents:
When you're considering developing a service layer, it should be clear to the end consumer of the service what to pass in and what to expect; approach 2 doesn't handle that well. (Also, when doing SOAP with WCF and then loading from the wsdl in other .NET projects, it doesn't properly mark abstract classes, nor do interfaces get transferred. WSDLs have no way of describing a non-instantiable base class, it seems.)
Though, I must admit, I think the second process is great using the KnownTypeAttributes (as I see just now marc_s has posted) - I've used it myself when allowing for unknown future requirements.
我同意方法 #2 看起来更好——从 OOP 的角度来看。
但是：SOA/WCF 和多态性通常不太匹配 - SOA（至少在执行基于 SOAP 的调用时）需要可以在定义服务的 WSDL/XSD 中表达的具体类。
您可以使用基于通用基本类型的派生数据类型 - 如果这样做，您必须查看KnownType 属性（或 ServiceKnownType) 向 WCF 发出信号，表明您可能返回的内容与操作合同实际上所说的不同。
I agree approach #2 looks better - from an OOP standpoint.
But: SOA/WCF and polymorphism typically don't match too well - SOA (at least when doing SOAP based calls) needs concrete classes that can be expressed in the WSDL/XSD that defines your service.
You can use derived datatypes based on a common base type - if you do, you'll have to look into the KnownType attribute (or ServiceKnownType) to signal to WCF that you might be returning something else than the operation contract actually says it will.