Когда вы используете JSP и когда сервлет?

Ответ 1

JSP скомпилирован в сервлет при первом запуске. Это означает, что между ними нет реальной разницы во времени выполнения.

Однако большинство из них традиционно используют сервлеты для контроллеров и JSP для представлений. Поскольку контроллеры - это только классы Java, вы можете получить полную поддержку инструмента (завершение кода и т.д.) Из всех IDE. Это дает лучшее качество и более быстрое время разработки по сравнению с JSP. Некоторые более продвинутые IDE (IntelliJ IDEA приходят на ум) имеют отличную поддержку JSP, что делает этот аргумент устаревшим.

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

Ответ 2

JSP: представить данные пользователю. Никакая бизнес-логика не должна быть здесь, и, конечно же, нет доступа к базе данных.

Сервлеты: для обработки ввода из формы или конкретного URL-адреса. Обычно люди используют библиотеку, такую ​​как Struts/ Spring поверх Servlets, чтобы очистить программирование. Независимо от того, что сервлет должен просто проверить данные, которые вошли, а затем передать его на реализацию бизнес-уровня бэкэнд (с которой вы можете кодировать тестовые примеры). Затем он должен поместить полученные значения в запрос или сеанс и вызвать JSP для их отображения.

Модель: модель данных, которая содержит ваши структурированные данные, которые обрабатывает веб-сайт. Сервлет может принимать аргументы, помещать их в модель и затем вызывать бизнес-уровень. Затем модель может взаимодействовать с внутренними DAO (или Hibernate) для доступа к базе данных.

Любой нетривиальный проект должен реализовывать структуру MVC. Разумеется, это чрезмерная функциональность. В вашем случае я бы выполнил сервлет, который вызвал DAO для обновления статуса и т.д. Или что-то еще.

Ответ 3

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

Я не знаю причин, по которым вы не можете использовать JSP, как вы описали (он все равно скомпилируется сервлетом с помощью утилизатора), но вы правы, предпочтительный метод - сделать его сервлетом в на первом месте.

Ответ 4

JSP - это ярлык для записи сервлета. Фактически они переводится на Java-код сервлета перед компиляцией. (Вы можете проверить его под каким-то подмножеством tomcat, который я не помню имени).

Чтобы выбрать между сервлет JSP, я использую простое правило: если страница содержит больше кода html, чем java-код, перейдите на JSP, иначе просто напишите сервлет. В общем, это грубо говоря: используйте JSP для презентации контента и сервлетов для контроля, проверки и т.д.

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

Ответ 5

Есть 2 довольно простых правила:

• Всякий раз, когда вы хотите написать Java-код (бизнес-логику), сделайте это в классе Java (так, Servlet).
• Всякий раз, когда вы хотите написать код HTML/CSS/JS (логика просмотра/шаблона), сделайте это в JSP.

Похожие вопросы:

• Как избежать кода Java в JSP

Ответ 6

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

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

Ответ 7

Я знаю, что сегодня это не самый популярный ответ, но: Когда я разрабатываю приложение с нуля, я всегда использую JSP. Когда логика нетривиальна, я создаю обычные классы Java для выполнения работы grunt, которую я вызываю из JSP. Я никогда не понимал аргумента, что вы должны использовать сервлеты, потому что, как чистые классы Java, они более удобны в обслуживании. JSP может легко называть чистый Java-класс, и, конечно, обычный Java-класс так же доступен для обслуживания, как любой сервлет. Легче отформатировать страницу в JSP, потому что вы можете поместить всю разметку в строку, вместо того, чтобы писать кучу println. Но самое большое преимущество JSP заключается в том, что вы можете просто оставить их в каталоге, и они доступны напрямую: вам не нужно связываться с настройкой отношений между URL-адресом и файлом класса. Безопасность легко обрабатывается путем включения каждого JSP с проверкой безопасности, которая может быть одним оператором вызова, поэтому нет необходимости устанавливать безопасность в уровень отправки.

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

Ответ 8

Большинство java-приложений в наши дни основаны на шаблоне MVC... На стороне контроллера (сервлет) вы реализуете бизнес-логику. Контроллер сервлета обычно перенаправляет запрос на jsp, который будет генерировать фактический html-ответ (вид в MVC). Цель состоит в том, чтобы разделить проблемы... Тысячи книг были написаны по этому вопросу.

Ответ 9

В архитектуре MVC сервлеты используются в качестве контроллера и JSP в качестве представления. Но оба они технически одинаковы. JSP будет переведен в сервлет, либо во время компиляции (например, в JDeveloper), либо при первом доступе (например, в Tomcat). Таким образом, реальная разница заключается в простоте использования. Я уверен, что вам будет сложно отображать HTML-страницу с помощью сервлета; но напротив здравого смысла, на самом деле вам будет довольно легко закодировать даже довольно сложную логику внутри JSP (возможно, с помощью некоторого подготовленного вспомогательного класса). PHP ребята делают это все время. И поэтому они попадают в ловушку создания кодов спагетти. Поэтому мое решение вашей проблемы: если вам было проще кодировать JSP, и это не будет включать слишком много кода, не стесняйтесь кодировать в JSP. В противном случае используйте сервлет.

Ответ 10

Согласился со всеми вышеперечисленными соображениями о различиях между JSP и сервлетами, но вот пара дополнительных соображений. Вы пишете:

У меня есть приложение, которое отправляет клиента на другой сайт для платежи. Другой сайт, за пределами клиент, называет страницу на нашем сервер, чтобы сообщить нам, что такое статус имеет платеж. Вызываемая страница проверяет параметры, которые указаны по заявке на платеж и чекам чтобы увидеть, является ли транзакция известный нам. Затем он обновляет чтобы отразить статус. Эта все делается без какого-либо взаимодействия с клиентом.

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

Во-вторых, по этим линиям большинство использования сервлетов/страниц JSP за последние несколько лет были помещены в контекст такой структуры, как Spring или Struts. Я бы порекомендовал Spring, так как он предлагает вам полный стек того, что вам нужно, от страниц сервера до логики шлюза веб-сервисов для DAO. Если вы хотите понять гайки и болты Spring, я бы рекомендовал Spring в действии. Если вам нужно лучше понять, как на уровне архитектуры предприятия, написанной на языке Java (или С#), я бы рекомендовал шаблоны Fowler Enterprise Application Architecture.

Ответ 11

Да, это должен быть сервлет. JSP может быть проще в разработке, но сервлет будет легче поддерживать. Представьте, что вам нужно исправить случайную ошибку через 6 месяцев и попытаться вспомнить, как она работает.

Ответ 12

В Java-сервлете HTML-теги внедряются в java-кодирование. В JSP кодировки java встроены в теги HTML.

Для большого приложения для большой проблемы сервлет сложен для чтения, понимания, отладки и т.д. из-за нечитаемости встраивания большего количества тегов html в java-кодирование. Поэтому мы используем jsp.In jsp, это легко понять, и др.

Спасибо и с уважением, Sivakumar.j

Ответ 13

Я думаю, что это зависит от вас? потому как JSP - это Java внутри HTML и Servlet - это Java, который может выполнять HTML внутри

hmmm... servlet более sercure, чем jsp, потому что, если вы отправляете на Servlet и пересылаете на другой JSP, расширение файла не появляется, а также вы не можете видеть, что это за страница.

но преимущество JSP заключается в том, что вы можете легко его кодировать.