为什么我们在WCF中使用接口? [英] Why we use interface in WCF?

查看:154
本文介绍了为什么我们在WCF中使用接口?的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

大家好,



我在WCF工作时遇到了一些小疑问。我在互联网上寻找这个答案几天但没有找到关于这个主题的任何解释清楚的文章。



问题1:为什么我们在WCF中使用接口?

我们可以在不使用界面的情况下编写操作合同,数据合同等。我们可以定义一个简单实现操作合同的类。



问题2:为什么不抽象类而不是接口?

我们也可以使用Abstract Class实现相同的功能。我可以在Abstract Class中声明和定义契约方法,并且可以简单地继承抽象类。



谢谢:

Agnib Pyne



我尝试了什么:



我在互联网上搜索过得到这个疑问的完美解释。

Hi All,

I cam up with a small doubt while working on WCF. I am looking for this answer for few days over internet but couldn't find any well-explained article on this topic.

Question 1: Why we use interface in WCF?
We could have written the operation contracts, data contracts, etc., without using interface. We could have defined a class which would simply implement the operation contracts.

Question 2: Why not Abstract class instead of interface?
We could also implement the same using an Abstract Class. I could have declared and defined the contract methods in the Abstract Class and could have simply inherit the abstract class.

Thanks:
Agnib Pyne

What I have tried:

I have searched over internet to get a perfect explanation for this doubt.

推荐答案

根据定义,您不必使用任何接口,也不使用抽象类来使用WCF ...

接口被认为是最佳实践,因为它可以明确地组合同一个合同的重用(一个类可以实现多个接口,但只能继承一个类)...
By definition you have not to use no interfaces and no abstract classes to use WCF...
Interfaces are considered to be the best practice because it enables a wise combination of reuses of the same contract (a class can implement multiple interfaces but can inherit only one class)...


转过来问题:如果 使用界面会怎样?



嗯,有然后有两种方法:

1)定义一个抽象类。

2)定义一个具体的类。



抽象类的优势是什么?这里的界面?好吧,你可以在类中添加预定义的行为来添加默认处理 - 但是WCF不是关于处理,而是关于数据传输:所有可以默认的处理都已经在远程端完成了。那么究竟是什么可以添加到对数据的所有用户有用的抽象类?在实践中,没有 - 因为你不知道数据将用于什么。



具体课程怎么样?与抽象类相同的问题,没有什么好处。



这两个都会导致一个重大问题,因为C#不支持多重继承。因此,如果您使用抽象或具体类,则无法从任何其他类派生。这意味着你不能创建一个知道你的WCF源的TextBox,因为你不能同时从Control,TextBox或任何其他UI组件和WCF类派生。



接口没有这些限制,因此它是一个更好,更好的选择。它会强制您实施数据传输合同要求,而不会限制您随后对实施中的数据执行的操作。
Turn the question round: what happens if you don't use an Interface?

Well, there are then two ways to do it:
1) Define an abstract class.
2) Define a concrete class.

What is the "advantage" of an abstract class over an interface here? Well, you can add predefined behaviour to the class to add default processing - but WCF isn't about processing, it's about data transfer: all the processing that can be defaulted has been done at the remote end already. So what exactly can you add to the abstract class that is of any use to all users of the data? In practice, nothing - because you have no idea what the data will be used for.

What about a concrete class? Same problems as the abstract class, with no really benefits.

And both of them cause a major problem, because C# does not support multiple inheritance. So if you use an abstract or concrete class you cannot derive from any other class. Which means you can't create a TextBox that "knows" about your WCF source because you can't derive from Control, TextBox, or any other UI component and from the WCF class at the same time.

Interfaces have none of those restrictions, so it's a much, much better choice. It forces you to implement the data transfer contract requirements, without restricting what you can subsequently do with the data in your implementation.


这篇关于为什么我们在WCF中使用接口?的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆