Должен ли веб-фреймворк быть фильтром или сервлетом?

Question

Наличие веб-фреймворка для обработки запросов из одной точки входа - это решенная проблема. Однако должна ли эта единая точка входа быть Фильтром или Сервлетом? Почему разработчик веб-приложений предпочитает одно другому? Почему разработчик фреймворка предпочитает один другому?

Answer 1

Давайте посмотрим, как это делают существующие фреймворки:

• JSF : сервлет
• Spring MVC : сервлет
• Struts / Struts2 : сервлет в Struts1, фильтр в Struts2
• калитка : сервлет до 1,2, фильтр после 1,3
• полосы : Фильтр и Сервлет
• Эхо : Сервлет
• Ваадин : Сервлет

Это были самые популярные фреймворки.Их больше, но большинство из них используют сервлет.

Большинство, если не все сервлеты, должны отображаться в шаблоне URL суффикса, например, *.jsf (JSF), *.html (Spring), *.do (Struts) и т. Д. Это позволяетРазработчик легко игнорирует ресурсы, которые не представляют интереса.Таким образом, преимущество фильтра в том, что он может это сделать, исчезает.Только Wicket имел обыкновение отображаться на дополнительный путь /app/*, а изменение сервлета на Filter в Wicket 1.3 было сделано с единственным аргументом, что вы сможете отобразить его только на /*.Это, однако, добавляет дополнительный шаблон конфигурации, чтобы иметь возможность игнорировать статические ресурсы.Лично я не понимаю, почему они не просто использовали отображение суффиксов.

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

Кроме того, Sun / Oracle проводит четкое разделение между фильтрами и сервлетами по следующим причинам: когда вы хотите фильтр запросов / ответов на определенных условиях, используйте фильтр.Если вы хотите контролировать запросов / ответов и / или создавать ответы, используйте сервлет.

См. Также:

• Сервлет против фильтра
• Веб-приложения Design Patterns
• Как получить доступ к статическим ресурсам при сопоставлении сервлета глобального фронт-контроллера с / *
• Разница между / и / * в шаблоне отображения сервлета

Answer 2

Проверьте этот тест. Вы найдете Play! Framework (на основе Netty) + движок шаблонов Japid почти близок к статическому хостингу контента (даже при увеличении количества одновременных пользователей).

Answer 3

Фильтр из личного опыта.Я пришел к такому выводу, потому что в фильтре я могу решить, нужно ли мне обрабатывать запрос.Если мне не нужно справляться с этим, я могу просто позволить цепочке выполнить следующий фильтр.В сервлете, если вы решите не продолжать обработку, вам придется переадресовать, что, как я обнаружил, не сработало.

Answer 4

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

Answer 5

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

Теперь я бы сказал, что веб-инфраструктура даже не должна основываться на спецификации J2EE (согласно Play Framework ), в которой правилабыл полностью переписан, чтобы облегчить разработку веб-приложений для программиста на Java.