Сервисный слой VS Бизнес-слой в архитектуре веб-приложений?

Question

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

Итак, мы используем ASP.NET MVC 2 и иметь уровень доступа к данным, который выполняет все запросы с базой данных, а затем у нас есть бизнес-уровень, который имеет деловую логику, а также проверки, необходимые для выполнения. Наконец у нас есть презентационный слой, который в основном имеет все виды. Кроме того, у нас также есть некоторые помощники, DTOS и ViewModel в разных папках в составе наших библиотек. Но я пытался прочитать о архитектуре, и кажется, что сервисный слой является важной частью архитектуры.

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

Answer 1

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

Это позволяет применить специализированные шаблоны дизайна и лучших практик к каждому компоненту.

Например, работа бизнес-слоя является реализация бизнес-логики. Полная остановка. Выполнение API, предназначенное для употребления презентационного слоя, не является его «беспокойством».

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

Таким образом нет необходимости заниматься дизайном. приложение.

Каждый слой должен сделать одну работу очень хорошо. Роль прохождения между тем, что выполняет сервисный слой, является одним из таких четко определенных заданий, и это является причиной его существования: это единица сложности, которая является разрабатываемой таким же образом снова и снова, а не на необходимость нанесения колеса Каждый раз, чтобы убить эту роль с бизнес-логикой, где она не принадлежит. Думайте об сервисном слое как сопоставление компонента. Это внешнее на бизнес логику и не принадлежит в его классах, либо в контроллерах.

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

ASP.NET MVC Ничто, если не платформа, позволяющая вам написать приложения в качестве специализированных компонентов.

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

Answer 2

Вы можете найти термин Архитектура астронавт интересный.

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

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

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

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

Answer 3

В некоторых конструкциях сервисный слой не используется на уровне презентации.

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

В некотором смысле, сервисный слой является еще одним интерфейсом отдельно от слоя презентации.

Увидеть архитектурная диаграмма здесь. Пользователи получают доступ к приложению через слой презентации. И внешние системы доступа к приложению через слой сервисов. Слой презентации и слой сервисов разговаривают с фасадом приложения в бизнес-уровне.

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

Как указывает Крис живой, никто не должен увлекать с созданием слоев. Я бы порекомендовал только создание слоев, которые были бы полезны в вашем приложении. По моему опыту потребность в сервисном слое не часто, но потребность в бизнес-слое очень часто.

Answer 4

Сервисный слой обычно построен с точки зрения дискретных операций, которые необходимо поддерживать для клиента.

Например, сервисный слой может выставлять создание учетной записи. Принимая во внимание, что бизнес-слой может состоять из проверки параметров, необходимых для создания учетной записи, построение объектов данных для сохранения и т. Д.

Часто у сервисного слоя используются процедурный или код стиля сценариев транзакции для оркестрата бизнес и / или логических слоев.

Зная это, вы можете понять, что ваш Бизнес-слой на самом деле Сервисный слой также. В какой-то момент точка, от которой вы задаете этот вопрос, являетесь одним таким точком, различие в основном семантическое.

Answer 5

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

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

Служба обслуживания позволяет вам дополнительно отделить интерфейс от бизнеса. Или даже поменяйте другие бизнес-слои в зависимости от изменяющихся сценариев бизнеса.

Не каждое приложение не нуждается в одном, хотя (многие переменные попадают в это определение), слишком много архитектуры может ввести сложность, которые ваша команда может не понадобиться.

Answer 6

Посмотрите, что Рэнди Стаффорд говорит о сервисном слое в книге «P O EAA»http://martinfowler.com/eacatalog/serviceLayer.html.

Сервисный слой определяет границу приложения [POLOP PLOP] и его набор доступных операций с точки зрения взаимодействия клиентских слоев. Он инкапсулирует бизнес-логику приложенияконтроль транзакций и координаковых откликов в реализации его операций.

Answer 7

Простой. Чтобы открыть вашу бизнес-логику клиенту, используйте сервисный слой. Спроси себя:

При изменении бизнес-логики следует ли изменять сервисный слой? Если ответ «не всегда», то необходим сервисный слой.

Answer 8

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

Еще одна вещь, которую я сделал, используется, чтобы перевести между объектами доменов и DTOS. Бизнес-слой имеет дело с моделью домена, но я передал данные обратно в презентационный слой в виде DTOS (в некоторых случаях не было практично, чтобы разоблачить всю доменную модель до уровня презентации по разным причинам), Таким образом, сервисный слой обрабатывает это отображение.

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

Answer 9

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