Member 11072126 Ответов: 3

Почему мы используем интерфейс в WCF?


Всем Привет,

Я столкнулся с небольшим сомнением, работая над WCF. Я ищу этот ответ в течение нескольких дней через интернет, но не смог найти ни одной хорошо объясненной статьи на эту тему.

Вопрос 1: Почему мы используем интерфейс в WCF?
Мы могли бы написать операционные контракты, контракты на передачу данных и т. д., не используя интерфейс. Мы могли бы определить класс, который просто реализовывал бы операционные контракты.

Вопрос 2: Почему бы не абстрактный класс вместо интерфейса?
Мы также можем реализовать то же самое, используя абстрактный класс. Я мог бы объявить и определить контрактные методы в абстрактном классе и мог бы просто наследовать абстрактный класс.

Спасибо:
Агниб Пайн

Что я уже пробовал:

Я искал в интернете, чтобы получить идеальное объяснение этому сомнению.

3 Ответов

Рейтинг:
22

Kornfeld Eliyahu Peter

По определению, вы не должны использовать никакие интерфейсы и абстрактные классы для использования WCF...
Интерфейсы считаются наилучшей практикой, поскольку она позволяет разумно сочетать повторное использование одного и того же контракта (класс может реализовать несколько интерфейсов, но может наследовать только один класс)...


Member 11072126

Спасибо. Я полностью согласен с вами, что могу повторно использовать один и тот же интерфейс для многих классов.
А теперь у меня есть еще одно сомнение.:
Когда использовать абстрактный класс и когда использовать интерфейс?

Насколько я понимаю, абстрактный класс используется для отношений IS-A и интерфейса для отношений HAS-A. Но, кроме того, для отношений HAS-A я могу использовать абстрактный класс вместо использования интерфейса.

Во-вторых, если моему классу нужно объявлять переменные, то я могу пойти на абстрактный класс вместо интерфейса. Но я могу реализовать то же самое с помощью интерфейса, что и объявить свойства.

Таким образом, я не могу точно различить, когда использовать абстрактный класс и интерфейс

Kornfeld Eliyahu Peter

Погуглите "абстрактный класс C# против интерфейса" и начните читать...

Member 11072126

Да, я читал разные статьи. Но, единственный действительный момент, который я получаю, заключается в том, что я для интерфейсов, я могу реализовать несколько интерфейсов, но не возможно с абстрактным классом. Анализируя другие моменты, можно увидеть, что одно и то же возможно как для абстрактного класса, так и для интерфейса.

Рейтинг:
15

OriginalGriff

Переверните вопрос: что произойдет, если вы не использовать интерфейс?

Ну, тогда есть два способа сделать это:
1) Определите абстрактный класс.
2) определите конкретный класс.

В чем здесь "преимущество" абстрактного класса перед интерфейсом? Ну, вы можете добавить предопределенное поведение в класс, чтобы добавить обработку по умолчанию, но WCF - это не обработка, а передача данных: вся обработка, которая может быть выполнена по умолчанию, уже выполнена на удаленном конце. Итак, что именно вы можете добавить к абстрактному классу, который может быть полезен всем пользователям данных? На практике ничего - потому что вы понятия не имеете, для чего будут использоваться эти данные.

А как насчет конкретного класса? Те же проблемы, что и у абстрактного класса, но без каких-либо реальных преимуществ.

И оба они вызывают серьезную проблему, потому что C# не поддерживает множественное наследование. Поэтому, если вы используете абстрактный или конкретный класс, вы не можете быть производными от любого другого класса. Это означает, что вы не можете создать текстовое поле, которое "знает" о вашем источнике WCF, потому что вы не можете получить его из элемента управления, текстового поля или любого другого компонента пользовательского интерфейса и из класса WCF одновременно.

Интерфейсы не имеют ни одного из этих ограничений, так что это гораздо, гораздо лучший выбор. Это заставляет вас выполнять требования контракта на передачу данных, не ограничивая то, что вы можете впоследствии сделать с данными в вашей реализации.


Member 11072126

Спасибо. Но я не получил преимущества использования абстрактного класса над интерфейсом.
Предположим, у меня есть интерфейс с именем "ITransact", и он содержит метод с именем "respModel Show(reqModel)", который принимает requestObject в качестве аргумента и отправляет обратно responseObject.
Теперь тот же самый метод может быть записан как абстрактный метод в абстрактном классе, и я могу использовать наследование абстрактного класса вместо реализации интерфейса.

Да, конечно, я не могу использовать наследование более одного класса, но могу реализовать несколько интерфейсов. Кроме этого момента, есть ли еще какие-то основные преимущества использования интерфейса?

Kornfeld Eliyahu Peter

Речь идет не о преимуществах - так как нет абсолютных преимуществ ни для того, ни для другого... Все дело в балансе возможностей и требований.
Не пытайтесь найти решение "один за всех", так как вы потерпите неудачу... Начните заново с каждой проблемы и используйте только свои знания и опыт...

OriginalGriff

Перестаньте искать "преимущество использования интерфейса в WCF" и посмотрите на недостатки его отсутствия: главное, что вы не можете наследовать от двух классов. И это ограничивает то, что вы потенциально можете сделать чрезвычайно: вам придется использовать инкапсуляцию и увеличить количество классов, чтобы использовать WCF.

В этом преимущество интерфейса при любых обстоятельствах: он вообще не имеет реализации по умолчанию, поэтому его можно вывести вместе с подходящим базовым классом, не нарушая контракт, который подразумевает интерфейс. Это не ограничивается WCF!

Member 11072126

Все еще сомневаюсь. Но в любом случае спасибо вам и Корнфельду за ваши ответы и объяснения. Это было определенно полезно.

OriginalGriff

Всегда пожалуйста!

Рейтинг:
0

Member 14980454

В соответствии с моим занижением давайте рассмотрим , что вы разместили одну службу WCF и хотите опубликовать два метода: один-для вашей организации, который будет содержать сведения о ваших компаниях, а другой-для вашего клиента, поэтому, если вы используете абстрактный класс, вы можете использовать эту службу либо для своей организации, либо для своего клиента.