Уровень обслуживания против бизнес-уровня в архитектуре веб-приложений?
Я знаю, что это может показаться глупым, но мне трудно понять необходимость сервисного уровня и его различия с бизнес-уровнем.
Итак, мы используем asp.net mvc 2 и имеет уровень доступа к данным, который выполняет все запросы с базой данных, а затем у нас есть бизнес-уровень, который имеет бизнес-логику и проверки, необходимые для выполнения. Наконец, у нас есть слой презентации, который в основном имеет все представления. Кроме того, у нас также есть некоторые помощники, DTOs и классы viewmodel в разных папках как часть наших библиотек. Но я попытался прочитать об архитектуре, и кажется, что уровень обслуживания является важной частью архитектуры.
все, что я понимаю, это то, что уровень обслуживания-это то, что вызывает все функции. Но я не вижу необходимости в уровне обслуживания в нашем приложении ? Или он уже там, а я его не вижу... Может ли кто-нибудь объяснить на примере, как важен уровень обслуживания ? Как это разные из бизнес-слоя, потому что из того, что я прочитал, кажется довольно похожим? Если ее в первую очередь нужно вообще ? Все, что мы пытаемся сделать, это архитектор нашего приложения в лучшем виде, каковы ваши мысли и опыт на нем ?
9 ответов
речь идет о разделении вашего приложения на автономные части, каждая из которых определяется требованием выполнить одну работу очень хорошо.
Это позволяет применять специализированные шаблоны проектирования и рекомендации к каждому компоненту.
например, задача бизнес-уровня заключается в реализации бизнес-логики. Точка. Предоставление API, предназначенного для использования на уровне презентации, не является его "проблемой".
этот роль go between лучше всего выполнять на уровне сервиса. Факторинг этого специализированного слоя позволяет применять гораздо более специализированные шаблоны к каждому отдельному компоненту.
нет необходимости делать дизайн таким образом, но накопленный опыт сообщества показывает, что это приводит к применению, которое намного проще разрабатывать и поддерживать, потому что вы точно знаете, что каждый компонент должен делать, даже до того, как вы начнете кодировать приложение.
каждый слой должен делать одну работу очень хорошо. Роль go between, которую выполняет сервисный уровень, является одной из таких четко определенных задач, и это причина ее существования: это единица сложности, которая спроектирована одинаково снова и снова, а не изобретать колесо каждый раз, чтобы калечить эту роль с бизнес-логикой, где она не принадлежит. Подумайте о слое сервиса как о компоненте отображения. Он является внешним по отношению к бизнес-логике и не принадлежат к его классам или к контроллерам.
кроме того, в результате учета бизнес-логики вы получаете более простые бизнес-объекты, которые легче использовать другими приложениями и службами, которые потребляет "бизнес".
ASP.NET MVC-это не что иное, как платформа, позволяющая писать приложения в качестве специализированных компонентов.
в результате этого растущего понимания того, как специализировать компоненты, программы развиваются из первобытная миска супа и спагетти во что-то другое и странное. Сложность, которую они могут решить, все еще используя простые структуры, увеличивается. Эволюция идет. Если жизнь-это что-то, чтобы идти, это должно быть хорошо, поэтому держите мяч.
вы можете найти термин Астронавт Архитектуры интересные.
дело в том, что не попадайте во все эти "слои", о которых люди болтают. Каждый раз, когда у вас был другой слой приложения, в нем должна быть цель.
например, некоторые люди успешно совмещают понятия доступа к данным и бизнес-логики в одном. Это не правильно для каждого решения, но это отлично работает для многих из них. Некоторые люди может даже сочетать презентацию с бизнесом... что является основным нет-нет во многих кругах, но, опять же, может быть идеальным для необходимость вопрос.
в основном, проблема, которую вы решаете, должна диктовать структуру приложения. Если другие приложения должны интегрироваться с вашими, то может потребоваться добавить сервисный уровень. Это может принимать форму простых веб-форм, в которые другие могут размещать данные, или это может пойти дальше, чтобы быть полным на веб-службах. Может быть, даже ситуации, в которых вы хотите, чтобы уровень сервиса был основным, переходят в расположение для нескольких презентаций.
вы можете получить так сложно, как вы хотите, но хорошее правило, чтобы сохранить его простым, пока осложнения становятся необходимыми.
в некоторых конструкциях слой сервиса не используется слоем представления.
уровень сервиса вызывается другими приложениями, которые хотят использовать бизнес-уровни и уровни доступа к данным в приложении.
в некотором смысле, уровень сервиса является еще одним интерфейсом, отдельным от уровня представления.
посмотреть архитектурно-схемы здесь. Пользователи получают доступ к приложению через уровень представления. И внешний системы получают доступ к приложению через уровень служб. Уровень представления и уровень служб взаимодействуют с фасадом приложения на бизнес-уровне.
в качестве примера того, что могут быть эти другие "внешние системы", веб-службы и службы WCF вызывают уровень службы. Некоторые другие веб-приложения могут вызвать уровень обслуживания этого приложения в вызове веб-службы. Это был бы один из способов гарантировать, что оба приложения применяют одну и ту же бизнес-логику и что любые внесенные изменения для бизнес-логики отражены в обоих приложениях.
Как указывает Крис Лайвли, не следует увлекаться созданием слоев. Я бы рекомендовал создавать только те слои, которые будут полезны в вашем приложении. По моему опыту, потребность в сервисном слое встречается не часто, но потребность в бизнес-слое очень часто.
уровень обслуживания обычно строится в терминах дискретных операций, которые должны поддерживаться для клиента.
например, уровень сервиса может предоставлять возможность создания учетной записи. В то время как бизнес-уровень может состоять из проверки параметров, необходимых для создания учетной записи, построения объектов данных для сохранения и т. д.
часто уровень сервиса использует код процедурного или транзакционного стиля сценария для организации бизнеса и / или логики слои.
зная это, вы можете понять, что код Бизнес-Уровня действительно уровень обслуживания также. В какой-то момент точка, с которой вы задаете этот вопрос, является одной из таких точек, различие в основном семантическое.
с моей точки зрения, сервисный уровень позволяет изолировать уровень презентации от бизнес-уровня, точно так же, как бизнес-уровень и уровень доступа к данным изолируют вас от того, как вы сохраняете данные.
внутри вашего бизнес-слоя вы бы поместили вещи, которые имеют решающее значение для вашего "бизнеса". Надуманным (и, вероятно, плохо продуманным примером) было бы иметь это место, где происходят, скажем, дисконтные цены на продукт.
уровень обслуживания позволяет вам далее отделите интерфейс от бизнеса. Или даже поменять местами другие бизнес-слои в зависимости от меняющихся сценариев бизнеса.
не каждому приложению нужен один, хотя (много переменных входят в это определение), слишком много архитектуры может ввести сложности, которые вашей команде могут не понадобиться.
посмотрите, что Рэнди Стаффорд говорит о слое обслуживания в книге " P of EAA http://martinfowler.com/eaaCatalog/serviceLayer.html
уровень сервиса определяет граница приложения [Cockburn PloP] и набор доступных операций с точки зрения взаимодействия слои клиента. он инкапсулирует бизнес-логика приложения, контрольные операции и координации ответных мер в осуществление своей деятельности.
простой. Чтобы предоставить бизнес-логику клиенту, используйте уровень сервиса. Спросите себя:
при изменении бизнес-логики должен ли меняться уровень сервиса? Если ответ "не всегда", то необходим уровень обслуживания.
Я знаю, что этот поток старый, но одна полезная вещь, которую я сделал на уровне сервиса, - это обработка транзакций (бизнес-уровень не должен знать, как обрабатывать откаты, порядок операций и т. д.).
еще одна вещь, которую я сделал, используется для перевода между объектами домена и DTOs. Бизнес-уровень имеет дело с моделью домена, но я передал данные обратно на уровень представления в виде DTOs (в некоторых случаях было нецелесообразно выставлять весь домен модель для слоя представления по различным причинам), поэтому слой сервиса обрабатывает это сопоставление.
в конечном счете, я вижу бизнес-уровень как более мелкозернистый, тогда как сервисный уровень может быть более грубым, поскольку он может вызывать несколько операций в BLL и заказывать вызовы в пределах одного вызова службы.
да, и я бы также отметил, что уровень сервиса является хорошим местом для аутентификации, как на основе ролей, так и на основе пользователей.