Мой вопрос заключается в том, имеет ли смысл разделять контракт и реализацию на отдельные библиотеки DLL, и должно ли приложение (я) ссылаться на библиотеки Common / Impl, или же приложение (я) должно просто сделать сервис ссылка (с помощью «Создать ссылку на службу» или SvcUtil). Я думаю, что для приложений может иметь смысл просто ссылаться на сервис, чтобы вы не связывали Common / Impl с приложением. В этом случае имеет ли смысл создавать клиентский класс в MyService.Impl?
Бинго - ты "получил" это! Даже если теоретически технически может совместно использовать контракты и интерфейсы с использованием общих сборок, я бы рекомендовал не делать этого.
Прежде всего, другие клиенты (например, Java, PHP, Ruby) не смогут использовать общие сборки .NET. Поэтому внезапно они используют интерфейс, отличный от вашего клиента, что может привести к незначительным изменениям, которые трудно отладить.
Во-вторых, SOA - это разделение частей вашей системы на отдельные, отдельные объекты с четко определенными границами обслуживания. Совместное использование сборок вводит зависимости, которые вы пытаетесь избежать.
Поэтому, поэтому, я бы согласился, что вы на правильном пути - можно ли обсуждать, отделить ли контрактные интерфейсы от их конкретной реализации. Одним из преимуществ может быть то, что вам когда-либо понадобится создать вторую, третью реализацию тех же интерфейсов или если у вас есть определенные часто используемые вспомогательные интерфейсы в отдельной сборке, используемой различными вашими службами. Еще одна сборка на самом деле не помешает - я бы порекомендовал сделать именно так, как вы обрисовали в своем посте!
Марк