Бизнес Логика на стороне клиента

Question

Почему люди говорят, что бизнес-логика должна быть реализована в коде на стороне сервера (например, EJB), а не в коде клиентского приложения?

Пример, который я имею в виду, - это проверка бизнес-объектов в архитектуре на основе EJB.Действительно ли он должен быть делегирован в EJB или нормально запускать его на клиенте перед отправкой объекта на сервер для сохранения?

Answer 1

Проверка может быть сделана на стороне клиента, чтобы сохранить двустороннюю передачу на сервер.Но сервер также должен выполнить ту же проверку.В идеале вы можете использовать одни и те же классы как на стороне клиента, так и на стороне сервера.

Answer 2

Есть две причины.Во-первых, у вас может быть одинаковая бизнес-логика для нескольких клиентов, поэтому имеет смысл выделить ее на сервер.Во-вторых, вы, скорее всего, не можете доверять клиенту, а это значит, что проверка сервера необходима.

Answer 3

Почему люди говорят, что бизнес-логика должна быть реализована в коде серверной части (например, EJB), а не в коде клиентского приложения?

Это то, что мы узнали от клиента/ серверные (толстые клиенты) архитектуры.С такими архитектурами вам пришлось перераспределить всех клиентов, чтобы что-то изменить, и это было просто больно.Приложения на стороне сервера и централизованное развертывание (с тонкими или расширенными клиентами) не имеют этой проблемы и поэтому являются предпочтительными.

В качестве примера я имею в виду проверку бизнес-объектов в архитектуре на основе EJB,Действительно ли он должен быть делегирован в EJB или нормально запускать его на клиенте до того, как объект будет отправлен на сервер для сохранения?

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

Answer 4

Потому что обычно клиентский код используется для отображения информации, а не для определения того, что делает приложение.

В основном потому, что это дает вам гибкость в добавлении других клиентов без необходимости выполнять странные приемы (например, копирование / вставка)

Например, предположим, что ваш клиент использует HTML, позже вы захотите добавитьновый клиент, использующий JSON.

Если бизнес-правила были на клиенте, вам придется скопировать их на нового клиента.

Теперь не путайте с правилами валидации и другими.Они также должны быть размещены на стороне клиента.