Использование сервисного справочного подхода снимает некоторые начальные ограничения с использования WCF, потому что он генерирует код для вас, который упрощает вашу жизнь в те ранние дни WCF. Однако по мере того, как вы все больше привыкли к использованию WCF и понимаете, что на самом деле делает ссылка на службу, вы начинаете понимать, что подход с использованием службы иногда является скорее помехой, чем помощью.
Например, в моем случае у меня был сервис WCF, который использовался тремя разными проектами - двумя проектами C # и одним управляемым проектом C ++. Каждый раз, когда я обновлял интерфейс службы WCF, мне приходилось заново генерировать ссылку на службу в каждом из этих трех проектов. Для меня это быстро стало головной болью.
Кроме того (и вы сталкиваетесь с этим), метод справочного обслуживания относится только к структуре ваших классов DataContract, а не к их поведению. Поэтому, если вы добавляете вспомогательные методы в классы DataContract на стороне сервера, это поведение необходимо добавить вручную на стороне клиента, поскольку оно не передается с помощью операции обмена метаданными (MEX).
Вот когда я наткнулся на это видео . В нем Мигель Кастро представляет убедительный случай, чтобы вообще не использовать сервисный подход. И когда вы исследуете его аргумент, это действительно имеет большой смысл.
Исходя из его рекомендаций, я бы предложил поместить ваши классы DataContract и классы, которые над ними работают, в библиотеку классов, на которую напрямую ссылаются (без ссылки на сервис) как Клиент, так и Сервер. Как вы увидите из видео, довольно просто написать код на стороне клиента и просто обновить его при изменении интерфейса WCF.
Я использовал этот подход уже пару месяцев, и обнаружил, что решение гораздо более гибкое, чем использование WCF, чем использование справочного подхода к услугам.