Можете ли вы построить RESTful Business Logic Layer?

Я создал службу RESTful для уровня доступа к данным (DAL) моей архитектуры:

POST http://example.com/data/User
GET|PUT|DELETE http://example.com/data/User/{UserId}

Однако для уровня бизнес-логики (BLL) используется вторая служба, отличная от RESTful:

POST http://example.com/accountapi/register
POST http://example.com/accountapi/login

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

Как бы вы улучшили эту архитектуру?

  • Если служба BLL вызывает службу DAL?
  • Должен ли я отказаться от службы DAL и только открыть службу BLL?
  • Должен ли я каким-то образом внедрить бизнес-логику в службу RESTful DAL? Если да, то как?

ОТВЕТЫ

Ответ 1

(1) Избегайте, чтобы ваш (бизнес-логический уровень) веб-службы веб-сервиса делал дополнительные (RESTful) HTTP-запросы на уровень доступа к данным. Конечно, это будет менее эффективно, чем прямые вызовы методов. Но что еще более важно, вам потребуется развернуть веб-службы BLL и веб-службы DAL на отдельные экземпляры веб-сервера (или отдельные кластеры). В противном случае вы можете иметь случай, когда все ваши рабочие потоки HTTP заняты, пытаясь обслуживать BLL-ответы, и каждый из них заблокирован без проблем для бесплатного рабочего потока HTTP, чтобы служить ему ответом DAL. Это может привести к остановке (если вы выполняете тайм-аут/повторную обработку) или прямые взаимоблокировки (если вы этого не сделаете).

(2 и 3) Если вашим клиентам веб-сервисов необходимы как бизнес-логика, так и доступ к данным, предоставляйте их как единый набор услуг. Внутри они оба зависят от одних и тех же вызовов метода доступа к доступу к данным: это просто, что реализации веб-сервисов, ориентированных на данные, делают только один вызов уровня доступа к данным, в то время как реализации бизнес-ориентированных веб-сервисов могут совершать много вызовов DAL. Вы определенно хотите структурировать слои BLL и DAL отдельно под слоем веб-сервиса.

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

Ответ 2

Чтобы ответить на главный вопрос. Нет, не совсем. Чтобы ответить на второстепенные вопросы. Ничего из перечисленного.

Архитектуры, основанные на REST, не вписываются в стандартную трехуровневую модель. Упрощенный вид трехуровневой модели выглядит следующим образом:

Презентационный уровень ↔ Бизнес Logic Layer ↔ Уровень данных

Рассмотрим на мгновение разрыв слоя презентации на две части,

Rendering Layer ↔ Пользовательский интерфейс Содержимое ↔ BLL ↔ DAL

Если вы думаете о регулярном веб-приложении, браузер принимает содержимое HTML, CSS и Javascript и визуально визуализирует их в браузере. Это уровень содержимого пользовательского интерфейса, к которому применяются ограничения REST. Это наиболее очевидно, если вы думаете об ограничении гипермедиа. Интерфейсы REST являются средними для навигации, как и пользовательские интерфейсы. Интерфейсы REST возвращают re представление ресурсов.

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

Клиент REST ↔ Интерфейс REST ↔ BLL ↔ DAL

На мой взгляд, клиенты REST выпускаются в двух формах: либо очень тонкие средства рендеринга медиа-типа (например, веб-браузеры), либо скребки экрана (пауки, mashups). Я использую термин "экранный скребок" свободно, потому что, если вы правильно выбираете медиа-типы, клиент должен очистить данные от содержимого вашего пользовательского интерфейса.

Любая попытка выявить слои бизнес-логики как интерфейсов REST обычно имеет несколько эффектов. Разработчики в конечном итоге спрашивают, как делать транзакции в REST. Они создают огромное количество связей между клиентом и интерфейсом BLL из-за необходимости выставлять семантически богатые представления. Они забывают о ограничении гипермедиа, потому что большая часть этой связующей информации недоступна на уровне бизнес-логики. И они начинают жаловаться на издержки производительности HTTP и текстовых типов контента.

Ответ 3

  • Если это одно и то же приложение, то вам, вероятно, следует, чтобы слой BLL вызывал слой DAL непосредственно в коде вместо повторного вызова службы. Это будет держать его более эффективным, сохраняя при этом основные цели кода отдельно (высокая сплоченность).

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

  • Возможно, нет. См. № 2.