Я размещаю службу WCF в организации, и я надеялся встроить клиента в сборочную DLL, чтобы упаковать ее и передать всем, кто хочет использовать эту службу.
Я мог бы создать библиотеку классов и просто добавить ссылку на службу, построить ее и распространить. Есть рекомендации по альтернативному подходу?
Я делал нечто подобное в своей предыдущей организации. У меня также было дополнительное требование, чтобы библиотека была видимой для COM, чтобы устаревшее приложение C ++ могло использовать API.
Я зашел так далеко, что не стал запрашивать у клиента какую-либо конфигурацию WCF, помимо передачи множества параметров через API (URL-адрес службы, тайм-ауты и т. Д.). WCF был настроен программно. Я находился в очень жестко контролируемой среде, где я точно знал клиентов библиотеки и мог влиять на их дизайн. Этот подход у меня сработал, но, как говорится, ваш опыт может отличаться.
На моей предыдущей работе мы всегда так поступали. У нас был бы проект библиотеки, который не содержал ничего, кроме генерации прокси SVCUTIL и связанного с ним файла конфигурации.
Таким образом, другие наши проекты могут использовать эту библиотеку, и у нас будет только одно поколение прокси. Отлично подходит для модели SOA.
В вашем случае вы можете распространять эту сборку, если хотите. Лично я считаю, что преимущества больше для внутренних дел, которые вы контролируете, но я полагаю, если бы вы действительно чувствовали себя милосердными, распространение версии .NET для использования клиентами было бы полезным.
Какой будет хост службы? Если это будет протокол на основе HTTP, его размещение в приложении ASP.NET имеет большой смысл. В противном случае, да, запустите библиотеку классов.
ОБНОВЛЕНИЕ на основе комментария
Упаковка клиента действительно зависит от того, что получатель собирается с ней делать. Если вы ориентируетесь на разработчиков или уже существующие внутренние приложения, то библиотека - отличный вариант (хотя я бы, вероятно, обернул ее в .msi, чтобы сделать работу знакомой для пользователей). Если должен быть пользовательский интерфейс, тогда, очевидно, вы захотите подумать о соответствующей структуре пользовательского интерфейса (WPF, Silverlight, WinForms и т. Д.).
Я бы просто предоставил библиотеку, содержащую все необходимые контракты. Вот и все - они могут написать свой собственный клиентский прокси.
Знают ли ваши пользователи, как использовать WCF? Если нет, включите прокси-класс, который создает экземпляр канала и вызывает службу.
Я действительно не вижу смысла предоставлять сборку, которая просто включает код, сгенерированный svcutil. Почему бы просто не дать вашим пользователям WSDL, а затем они смогут сами сгенерировать этот код? Распространение шаблона не кажется хорошей идеей.
