Почему бизнес-логика должна быть перенесена из JSP?

Ответ 1

Основное преимущество MVC заключается в том, что вы можете иметь несколько видов и чистую и разделенную архитектуру и Простота

Повторное использование

Предположим, что завтра вам понадобится одно приложение, работающее в настольном приложении. то вы можете просто изменить представление.

Возможность тестирования

Вы можете unit test ваши методы обслуживания, но вы не можете просто логику unit test из представления.

ремонтопригодность

Легко понять код из Сервисных методов, также мы можем изменить его/освободить сервис api и легко его поддерживать.

Возможность версии

Вы можете предоставить версию своего API и поддерживать стандартные документы, связанные с проблемами/обновлениями, если вы используете сервисный API вместо просмотра для логики

См. также

• Общие сведения о MVC
• Что такое MVC?
• Разделение концерна

Ответ 2

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

Еще одно преимущество SoC - уменьшить средний размер и сложность этих устройств. Это, в свою очередь, упрощает понимание и изменение вашего программного обеспечения.

Кроме того, с небольшими логическими единицами они значительно облегчают unit test, проще обманывать интеграционные тесты и легче исправить тесты после изменений в реализации.

Ответ 3

Я добавлю еще одну причину для всех очень хороших, которые публикуются здесь.

Клиентская технология постоянно меняется. Пользователи не хотят проходить через настольный компьютер, браузер или мобильное приложение; они хотят использовать их все время. Поэтому, если вы встраиваете бизнес-логику в один тип технологии пользовательского интерфейса, вам, вероятно, придется дублировать ее во всех остальных. Это плохо для обслуживания, повторного использования и добавления новой бизнес-логики.

Вы не хотите переписывать свое приложение только потому, что решили изменить технологию пользовательского интерфейса.

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

Таким образом, вам лучше поддерживать бизнес-логику на стороне сервера.

Ответ 4

• Он становится многоразовым (как для других приложений, так и для разных представлений (например, JSON API))
• Это отнимает у дизайнеров (так что это не мешает им, и они случайно не разбивают его).

Ответ 5

Я не уверен, но это может быть причиной:

Свойство для повторного использования.

Jsp должен использоваться только для презентации и нашего html-дизайнера, которые позже проектируют страница не знает о java-кодировании, будет неудобно. и запись всей логики логики в сервлете позволяет код reusable.and для написания логики логики на странице jsp там это как-то иначе, как использование scriplets.so, почему работа с меньшей прибылью и дополнительной работой.

Теперь, если мы используем jsp-страницу для бизнес-логики, тогда scriptlet будет больше внутри страницы JSP, что приведет к тяжелая поддержка. Отдельная декларация сервлета для бизнес-единицы будет избегайте всех выше.

Ответ 6

Просто добавьте хорошие аргументы, высказанные другими сверстниками, и в частности, что "бизнес-логика должна быть перенесена из JSP".

В двух словах на работе у нас было много JSP, где деловая логика закончилась, и это было довольно грязно, глядя на нее. Была логика получения объектов из сеанса/запроса и выполнения определенных проверок. Одним простым примером является построение различных заголовков страниц в зависимости от определенных условий в JSP.

Как эта логика была перенесена в наш конец, было введение объекта Page Builder/Composer, который принимает все необходимые детали для конструирования конкретной страницы и проверяет и устанавливает все правильные поля в объекте bean. Этот объект bean затем устанавливается по запросу, например. Это означает, что вся предыдущая логика, которую вы использовали бы в JSP, теперь перемещается в объект компоновщика страниц/композитора, а затем самое главное, вы можете написать тесты unit для тестов! если правильные значения установлены на странице bean.

final SimplePageBuilder pageBuilder = new SimplePageBuilder(object1);
request.setAttribute("TestBean", pageBuilder.buildPage());

Метод buildPage вернет объект bean страницы, а в jsp простой пример getTitle просто вернет заголовок (легко читаемый по мере абстрагирования логики).

Ответ 7

Лучше повторно использовать и поддерживать веб-приложение, если бизнес-логика отделена от логики представления.

Предположим, что у меня есть 3 страницы JSP, каждая из которых требует выполнения некоторой общей бизнес-логики. Если я поставлю бизнес-логику на страницах JSP, будет дублирование кода.