Можете ли вы создать RESTful Business Logic Layer?

Question

Я создал службу 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, напрямую обращается к базе данных.

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

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

Answer 1

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

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

Уровень представления <-> Бизнес Логический уровень <-> Уровень данных

Подумайте на мгновение, разбив презентационный слой на две части,

Уровень рендеринга <-> Пользовательский интерфейс Содержание <-> BLL <-> DAL

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

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

Клиент REST <-> Интерфейс REST <-> BLL <-> DAL

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

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

Answer 2

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

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

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

Answer 3

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

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

3. Вероятно, нет. См. № 2.