Можете ли вы построить 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

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

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

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

Answer 2

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

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

3. Наверное, нет. См. № 2.

Answer 3

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

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

Presentation Layer < -> Бизнес Logic Layer < -> Уровень данных

на минуту разорвать слой представления на две части,

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

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

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

REST Client < -> REST интерфейс < -> BLL < -> DAL

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

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