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

В настоящее время в нашем решении 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? Научи меня.


wcf projects-and-solutions
person Jeepasaurus    schedule 28.09.2010    source источник

Ответы (3)


arrow_upward
3
arrow_downward

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

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

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

person Shiraz Bhaiji    schedule 28.09.2010

arrow_upward
1
arrow_downward

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

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

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

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

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

person Kirk Broadhurst    schedule 28.09.2010

arrow_upward
0
arrow_downward

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

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

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

person Don Demsak    schedule 29.09.2010