Действительно ли сервлеты Java EE используются напрямую?

Я просто пытаюсь начать работу с Java EE и связанных концепций. Однако у меня возникли некоторые проблемы с пониманием отношений между некоторыми технологиями и ролями, которые они играют.

насколько я понимаю, сервлет Java EE - это класс Java, который работает внутри сервера и генерирует ответы на запросы (обычно HTML-ответы на HTTP-запросы, хотя сервлеты теоретически могут обслуживать любой протокол).

мои вопросы:

  • насколько я поймите, я могу либо написать класс сервлета напрямую, либо использовать некоторые технологии, такие как JSP или JSF, которые затем будут генерировать/предоставлять сервлет для меня. Во всяком случае, веб-контейнер Java EE (например, Apache Tomcat), где я в конечном итоге запускаю свое приложение, будет видеть только сервлеты и не будет заботиться о том, как они были созданы (поэтому сервлеты являются своего рода сантехникой низкого уровня). Это правда?
  • если сервлеты являются низкоуровневыми, есть ли причина использовать сервлеты напрямую? Я видел много учебники, которые объясняют, как написать сервлет, но это кажется довольно непрактичным. Есть ли ситуация, когда запись сервлета напрямую лучше/предпочтительнее использовать JSP или аналогичный?
  • наконец, Сервлетам нужен сервер для запуска (например, Apache Tomcat). При чтении о серверах в этом контексте я видел различные имена, такие как (Java EE) веб-контейнер или сервлет контейнер или контейнер JSP, или просто Java EE сервер. Все эти термины означают одно и то же, или есть разница?

Спасибо, что помогли мне начать!

9
java java-ee servlets

5 ответов

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

сервлеты низкого уровня. Они являются базовой абстракцией, на которой основаны все другие веб-фреймворки Java EE. В" реальном мире", большую часть времени, люди будут использовать некоторые рамки более высокого уровня, а не сырой Сервлет.

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

Что касается контейнеров, различие заключается в основном в Java EE server vs Servlet container или server. Tomcat не является сервером Java EE, он обрабатывает только веб-часть стека Java EE. Сбить с толку вещи, Java EE 6 теперь имеет "веб-профиль", который в основном является стеком сервлетов, но если раньше контейнер сервлетов не мог рассматриваться как" сервер Java EE", теперь он может быть"Java EE Server - Web Profile".

3

когда вы не используете структуру MVC, такую как JSF, Spring MVC, Struts и т. д., Вам все равно нужен сервлет для выполнения основного задания управления запросом/ответом. JSPs-хотя под обложками действительно компилируется в сервлеты - должен использоваться только как представление, а не как контроллер.

Я думаю, что ваша путаница вызвана относительно огромным количеством учебников низкого качества о сервлетах, где они используются для печати простого HTML out.print() заявления. Это с учетом MVC совершенно неправильно. Я бы предлагаем начать с нашей вики-страницы:https://stackoverflow.com/tags/servlets/info

11

  1. JSP и JSF-это технологии презентационного уровня. Хотя это правда, что JSP компилируются в сервлеты, и что вы даже можете написать простой Java-код внутри JSP, это очень плохой стиль кодирования. В общем, ваши JSP-файлы не должны содержать код Java и не должны делать такие вещи, как запрос базы данных вашего сервера или непосредственно проверять параметры запроса. Все это должно быть сделано в отдельном сервлете (или если вы используете веб-фреймворк, то ваш фреймворк абстракция сервлета) до попадания в JSP.

  2. в типичном случае кодирование сервлета для каждого запроса, который вы хотите обслуживать, нецелесообразно. Большинство веб-фреймворков Java полностью абстрагируются от интерфейса сервлета, так что вы можете создать полное webapp без прямой реализации сервлета. Однако могут быть случайные уникальные случаи, когда наиболее эффективно обойти веб-фреймворк и предоставить сервлет, который предоставляет некоторый особый случай функциональность.

  3. Они довольно близко к тому же, на самом деле. Все они являются контейнеры. Некоторые из них могут также включать другие функции Java EE за пределами поддержки сервлетов. Быть контейнером сервлетов не гарантирует поддержку дополнительных функций Java EE, но быть контейнером Java EE гарантирует поддержку сервлетов.

5

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

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

сервлеты выполняются в контейнерах сервлетов. Существуют технические различия между контейнером сервлета и контейнерами Java EE. Вы можете иметь первое без последнего, но вы не можете иметь последнее без первого (я думаю). Сервлеты являются одной частью стека Java EE. Другие части-это такие вещи, как JMS (messaging) и JMX (Management extensions), среди прочих.

2

рамки как JSF, JSP, распорки etc внутренне зависят от спецификации сервлета. Эти фреймворки построены только поверх сервлетов.

1