А есть ли смысл выносить поголовно все контракты из классов WCF-сервисов в интерфейсы?

buredРечь о СервисКонтрактах или ДатаКонтрактах?

Речь идёт о нужности ILogon . Я бы описал всё в самом классе SvcLogon, если не требуется чего-то особенного. Например, наследования контрактов или их повторного использования в разных сервисах.

buredЕсли первое, то по правде не вижу смысла, кроме эстетического.Просто в книжках пишут, что ServiceContract обязательно (!) нужно вынести в интерфейс, иначе появятся проблемы. Вот и хочу для себя понять, какие возможны проблемы и какова вероятность их появления непосредстванно у меня.

buredА. Не понял вопрос. СервисКонтракты не наследуются, как это можно сделать с ДатаКонтрактами, используя атрибут knowtype.
Хотя сами интерфейсы и можно выстроить в иерархию, но с т.з. WCF смысла в этом нет.Ну ладно, возможно я что-то напутал. Тут нужно подумать. :-)

buredА интерфейсы с аттр. [ServiceContract] нужны для формирования метаданных и прокси на стороне клиента. Наверное можно обойтись и без них (как в asmx, честно говоря не пробовал)

Можно обойтись и без интерфейса. И метаданные прекрасно формируются. И прокси на клиенте по ним генерится. Правда на клиенте интерфейсы будут называться SvcLogon и SvcLogonChannel, но это мелочи. :-)

buredно имхо это будет бэдпрактикс.Собственно, и хотелось бы выяснить, чем конкретно этот "бэдпрактикс" грозит.