Почему службы WCF используют интерфейсы в качестве контракта на обслуживание вместо абстрактного класса?

Question

Это вопрос, который мне задали в интервью.

Когда вы создаете сервис WCF, вы получаете два файла;"IService.cs" и "Service.cs".Почему это класс, реализующий интерфейс, а не класс, наследующий абстрактный класс?Не отвечайте, говоря, что вы не можете поместить атрибут [servicecontract] поверх абстрактного класса.Я знаю, что вы можете применять его только к интерфейсам, но почему?

Answer 1

WCF полностью отделяет клиента от службы, если вы указываете реализацию службы в качестве службы, которую вы тесно связали с клиентом со службой.

Answer 2

Можно реализовать более одного интерфейса. Можно наследовать только один абстрактный класс.

Answer 3

Несколько причин, по которым я могу придумать:

• Четкое утверждение о намерениях - «этот набор сигнатур API полностью отделен от любой возможной реализации».Напротив, абстрактный класс (на мой взгляд) - это скорее утверждение «этот базовый класс был разработан для работы с этим набором производных классов».
• Более открытый для модификации - как только вы унаследуете один базовый класс,вот и все.Поскольку [ServiceContract] не имеет реализации, зачем тратить на нее один слот наследования?Например, все наши классы обслуживания наследуются от абстрактного класса ServiceBase, который обеспечивает общее состояние контекста и методы, в дополнение к реализации интерфейса [ServiceContract].Однако, даже если бы это было не так, я бы оставил свободный слот базового класса для использования в будущем.
• Это позволяет одному классу обслуживания реализовывать более одного [ServiceContract], если это необходимо.
• Если вы используете систему контроля версий со строгим контрактом, которая полагается на наследование одного [ServiceContract] от другого, то добавление классов обслуживания в то же дерево наследования разрушит его.