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

Question

Каковы преимущества сохранения бизнес-логики вне JSP, поскольку JSP предназначены главным образом для представления?Мы по-прежнему видим бизнес-логику, написанную внутри JSP, поэтому мне нужно было знать, какую выгоду мы получаем, перенося бизнес-логику из JSP.

Answer 1

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

---

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

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

---

Тестируемость

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

---

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

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

---

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

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

---

См. Также

• Понимание MVC
• Что такое MVC?
• Разделение концерна

Answer 2

Это типичное применение принципа проектирования Разделение проблем .

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

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

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

Answer 3

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

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

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

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

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

Answer 4

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

Answer 5

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

Это для многократного использования цель.

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

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

Answer 6

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

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

Answer 7

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

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

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

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

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