Несколько проектов WCF против одного проекта в решении

Question

В настоящее время в нашем решении 12 проектов WCF. Каждый проект по сути своей конечной точки. Например, проект WCF «Заказ» является конечной точкой Order.svc. Эти 12 конечных точек представлены одним проектом WebHost. Проект WebHost имеет 12 файлов .svc, указывающих на каждую соответствующую сборку / пространство имен.

Мой вопрос вращается вокруг использования ОДНОГО проекта (одна сборка ... одна DLL) против нескольких проектов (несколько сборок ... несколько DLL). Каковы преимущества / недостатки, если таковые имеются? Конечный результат тот же ... у вас есть проект WebHost, который предоставляет эти конечные точки, указывающие на сборку / пространство имен. За исключением того, что вам просто нужно управлять одним .dll против 12 .dll в каталоге bin.

Для меня преимущества одного проекта: Поддерживаемость - вместо 12 проектов, каждый из которых имеет несколько ссылок на наши интерфейсы, контракты на данные, утилиты и т. Д., У нас есть один проект, в котором ссылки установлены в ОДНОМ месте. Затем мы можем развернуть одну DLL и использовать балансировщик нагрузки для равномерного распределения. Даже если мы явно размещаем 3 службы на сервере (то есть 4 сервера), если сервер выходит из строя, балансировщик нагрузки может настроить, а остальные 3 сервера будут иметь то, что им нужно, и позаботятся обо всем автоматически. (Я предполагаю, что то же самое верно и для 12 DLL. Просто убедитесь, что все 12 DLL на каждом сервере).

Время сборки - меньше проектов = быстрее время сборки. Visual Studio не нужно выполнять столько ссылок и копий .dll везде. Более быстрое время сборки = более продуктивный разработчик, а также более быстрая сборка и развертывание.

В настоящее время у меня есть пара коллег, обеспокоенных «тесным объединением» всех наших служб WCF в один проект. Для меня они все службы WCF, почему бы не поместить их в один и тот же проект? Конечные точки (файлы .svc) - это то, что их разделяет. Я также слышал вопрос: «А как насчет мертвого замка?». Что насчет этого? Это действительная проблема / проблема? (Честно говоря, я не знаю)

Также возникали вопросы о том, поврежден ли DLL-файл. Если это так, то все услуги не работают. Опять же ... это действительная проблема?

Все примеры, которые я видел от Microsoft и других, содержат службы WCF в одном проекте, разделенные разными классами. Интерфейсы находятся в их собственном проекте ... контракты данных в другом проекте и т. Д.

Итак, что вы берете? Как организовать несколько служб WCF в решении Visual Studio? Изучи меня.

Answer 1

Мы узнали это трудным путем. Недавно у нас был проект, в котором мы начинали с каждого сервиса в своем собственном проекте и в итоге конвертировали, чтобы все сервисы были в одном проекте. Основные проблемы с наличием вещей в разных проектах:

• Развертывание. Создаете ли вы 12 пакетов MSI по одному для каждой службы, будут ли они развернуты на отдельных веб-сайтах. Что операционные операции думают о запуске 12 скриптов установки и мониторинге 12 сайтов.
• Вызывают ли сервисы друг друга, если да, то через WCF может быть медленно, и конфигурация может быть кошмаром, 12 сервисов вызывают 11 сервисов, с конфигурацией для dev, test и prod.
• Также на сервисах, вызывающих друг друга, наблюдается снижение производительности по сравнению с прямым вызовом dll
• Имеют ли сервисы общую версию, когда, например, изменения базы данных изменят все сервисы. Если да, вам всегда нужно будет развернуть все сервисы. Это займет больше времени, чем одна услуга, ваше время простоя будет больше

Мы используем отдельные проекты для интерфейсов (контрактов) и объектов передачи данных.

Answer 2

Как правило, если мои SVC-файлы существуют в одной сборке, то они имеют какую-то цель.Если у svc достаточно общей цели, чтобы существовать в одной сборке, то реализация также имеет достаточно общей цели, чтобы существовать в одной сборке.

Нет проблем с их наличием в отдельных сборках, но их нетвыгоды тоже.Это больше о построении четко структурированного, поддерживаемого решения - и это в основном вопрос личных предпочтений / стандартов / стиля.

Разделите реализации, если вы обычно их разделяете - то есть, если они дают существенно разные результаты иливыступать в качестве отдельных компонентов вашего решения.Если одна сборка будет громоздкой, выделите ее.

Сосредоточьтесь больше на контрактах и ​​реализацияхОни служат различным (техническим) целям, и вы можете раскрыть контракты, не раскрывая реализации.

Сказав все это, я бы предпочел, чтобы они были в одной сборке, но разделены чистым пространством имен.Меньше сборок часто проще в управлении.

Answer 3

Помните, вам не нужно развертывать свои проекты так же, как вы управляете их разработкой. Вы всегда можете использовать такие вещи, как ILMerge, чтобы объединить несколько dll в одну dll, как часть шага сборки.

Я всегда рекомендую разрабатывать некоторые сервисы с использованием Фабрики программного обеспечения (также называемой Фабрикой программного обеспечения веб-сервисов), http://servicefactory.codeplex.com/, которая помогает применять набор «лучших практик» от команды MSFT Patterns & Practices. Это отличный способ изучить некоторые передовые практики, но как только вы изучите их, обычно лучше / проще просто применять их с помощью хороших руководств / обзоров кода с вашей командой разработчиков. Таким образом, вы можете использовать то, что работает в вашей среде, а не использовать то, что мешает.

Если у вас 12 служб, как вы можете управлять адом конфигурации, который может возникнуть? Особенно, если у вас есть услуги, которые зависят от других услуг. В конечном итоге размещение всего этого, а также любых пользовательских привязок и поведения в конфигурации может стать кошмаром развертывания. Кроме того, как вы делаете свои услуги известными другим на предприятии? Все ли делается из уст в уста, хорошего управления сборкой и контроля версий?