Должна ли веб-инфраструктура быть Фильтр или Сервл?

Ответ 1

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

• JSF: Сервлет
• Spring MVC: Servlet
• Struts/Struts2: Сервлет в Struts1, Фильтр в Struts2
• Wicket: сервлет до 1.2, фильтр после 1.3
• Stripes: Фильтр и сервлет
• Echo: Servlet
• Vaadin: Servlet

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

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

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

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

См. также:

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

Ответ 2

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

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

Ответ 3

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

Ответ 4

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

Ответ 5

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