Общий метод от клиента до БД в 3-уровневой архитектуре

Question

Должно ли бизнес-приложение полагаться на универсальный метод с именем saveOrUpdate от удаленного клиента до уровня постоянства гибернации?

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

Answer 1

Если вы делаете это, вы переносите свою бизнес-логику в клиента, просто и понятно.Это не обязательно плохо;посмотрите на требование HESTOAS REST, например, для ситуации, где это уместно.Однако, если вы пытаетесь сделать это, вы нарушаете парадигму, что сервер должен быть без состояния;если клиент указывает «saveOrUpdate», то вы предполагаете, что сервер поддерживает состояние после текущего сеанса, что является архитектурной проблемой, если вы когда-нибудь захотите масштабировать свои серверы горизонтально.По сути, если вы правильно управляете состоянием от клиента (как в ситуации с HATEOAS), ваши сохранения будут выполняться по мере выполнения запросов, и вам не понадобится "saveOrUpdate";если вам это действительно нужно от клиента, это означает, что вы неправильно перенесли свою бизнес-логику на клиент.

Answer 2

Если вы идете по этому пути, действительно ли вы 3-уровневая архитектура или просто 2-уровневая архитектура с мономолекулярным прозрачным «деловым» уровнем посередине?