Уровень обслуживания и бизнес-уровень в архитектуре веб-приложений?

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

Итак, мы используем asp.net mvc 2 и имеем уровень доступа к данным, который выполняет все запросы с базой данных, а затем у нас есть бизнес-уровень, который требует бизнес-логики и проверки. Наконец, у нас есть уровень презентации, который в основном имеет все представления. Кроме того, у нас также есть некоторые помощники, классы DTO и viewmodel в разных папках в составе наших библиотек. Но я попытался прочитать о архитектуре, и кажется, что уровень сервиса является важной частью архитектуры.

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

Ответ 1

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

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

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

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

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

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

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

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

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

Ответ 2

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

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

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

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

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

Ответ 3

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

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

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

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

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

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

Ответ 4

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

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

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

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

Ответ 5

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

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

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

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

Ответ 6

Посмотрите, что говорит Рэнди Стаффорд об Service Layer в книге "P EAA" http://martinfowler.com/eaaCatalog/serviceLayer.html

Уровень обслуживания определяет граница приложения [Cockburn PloP] и его набор доступных операций с точки зрения взаимодействия клиентских слоев. Он инкапсулирует прикладная бизнес-логика, контроля и координирующие ответы в осуществление его операций.

Ответ 7

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

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

Ответ 8

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

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

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

Ответ 9

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