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

Question

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

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

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

Answer 1

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

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

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

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

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

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

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

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

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

Answer 2

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

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

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

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

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

Answer 3

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

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

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

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

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

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

Answer 4

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

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

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

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

Answer 5

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

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

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

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

Answer 6

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

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

Answer 7

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

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

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

Answer 8

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

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

Answer 9

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