Должны ли службы на моем уровне обслуживания жить в отдельных проектах/библиотеках DLL/сборках?

Question

У меня есть приложение ASP.NET MVC 3, над которым я сейчас работаю. Я реализую уровень сервиса, который содержит бизнес-логику и который используется контроллерами. Сами сервисы используют репозитории для доступа к данным, а репозитории используют инфраструктуру сущности для связи с базой данных.

Таким образом, сверху вниз: Контроллер> Слой обслуживания> Репозиторий (каждый уровень обслуживания зависит от одного инъекционного репозитория)> Entity Framework> Single Database.

Я нахожу себе делать такие элементы, как UserService, Организация мероприятий, PaymentService и т.д.

В слое службы, я буду иметь такие функции, как:

• ChargePaymentCard(int cardId, decimal amount) (часть PaymentService)
• ActivateEvent(int eventId) (часть Организация мероприятий)
• SendValidationEmail(int userId) (часть UserService)

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

Кроме того, я хотел бы, чтобы мы открыли для расщепления (например, нашу единую базу данных) и перехода к сервис-ориентированной архитектуре в будущем, и некоторые из них были разбиты на веб-службы (возможно, даже для когда-нибудь будет использоваться приложениями .NET). Я не открывал глаз для шагов, которые могли бы сделать скачок к SOA менее болезненным в будущем.

Я начал путь создания отдельной сборки (DLL) для каждой службы, но я задаюсь вопросом, начал ли я неправильный путь. Я стараюсь быть гибким и держать вещи слабо связанными, но этот путь помогает мне в любом (к SOA или вообще) или просто добавляет сложности? Должен ли я вместо этого создать единую сборку/dll, содержащую весь мой сервисный уровень, и использовать эту единую сборку везде, где необходимо использовать какие-либо службы?

Я не уверен в последствиях путей, с которых я начинаю, поэтому любая помощь в этом будет оценена!

Answer 1

IMO - ответ зависит от множества факторов вашего применения.

Предполагая, что вы создаете нетривиальное приложение (т.это не колледж/хобби проект, чтобы узнать SOA):

• пользователя Услуга/Услуга Event/Оплата - Создайте свой собственный DLL & выставить его в качестве службы WCF, если существует более одного приложения используя эту услугу, и если это слишком большой риск для обмена DLL с различным приложением
  - Эти службы не должны иметь взаимозависимости друг от друга & должны сосредоточиться на своей отдельной области
  - Примечание: эти службы могут предоставлять некоторые общие службы, такие как ведение журнала, аутентификация, доступ к данным и т. д.

• Создание композиции сервисов - Эта услуга будет делать состав вызовов через все другие службы
  - Например: если у вас есть заказ, размещенный & бизнес-поток, что заказ Размещенный> Confirm Пользовательские службы (Служба пользователя)> Подтверждение платежа (Служба событий)> Подтверждение платежа (платежная услуга)
  - Весь такой состав вызовов обслуживания можно обрабатывать на этом уровне
  - Опять же, в зависимости от среды, вы может выставить эту службу как свою собственную DLL и/или опубликовать ее как WCF
  - Примечание: это i ы единственный сервис, который будет разделять ссылки на другие услуги & будет единая точка композиции

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

В качестве отправной точки я бы рекомендовал вам ознакомиться с любой из книг по архитектуре SOA - это поможет устранить множество концепций.

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

HTH.

Answer 2

Наличие одной библиотеки DLL в сервисе звучит как плохая идея. По словам Microsoft, вы хотите иметь одну большую сборку по нескольким более мелким из-за последствий производительности (от here через this post).

Я бы разделил ваши базовые или основные службы на отдельный проект и сохранил в нем большинство (если не все) сервисов. В зависимости от ваших потребностей у вас могут быть сервисы, которые имеют смысл только в контексте веб-проекта или консольного приложения, а не где-либо еще. Эти услуги не должны быть частью «основного» уровня обслуживания и должны находиться в соответствующих проектах.

Answer 3

Лучше отделить услуги от потребителей. В наших экспериментах мы имеем два уровня разделения. Мы объединили все интерфейсы службы в один проект Visual Studio. Все сервисные реализации сгруппированы в другой проект. Потребителю услуг необходимо ссылаться на две dll, но это делает решение более удобным и масштабируемым. Мы можем иметь несколько реализаций сервисов. . сервисный интерфейс может определить контракт для WebSearch в проекте интерфейсов. И может быть множество реализаций WebSearch через разных поставщиков поисковых услуг, таких как поиск Google, поиск Bing, поиск Yahoo и т. Д.