Один или несколько сервлетов в веб-приложении?

Question

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

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

Итак, каков ваш опыт, что работает лучше всего?

Answer 1

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

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

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

[РЕДАКТИРОВАТЬ] Перечитывая ваш вопрос, кажется, что вы используете термин site для обозначения страницы или просмотра. Опять же, это зависит от того, что происходит с этой точки зрения. Например, чтобы отобразить самую новую запись в блоге, у вас может быть сервлет, который создает список записей из базы данных для отображения. Если пользователь нажимает на запись, другой сервлет может получить эту запись для просмотра и так далее. В основном, каждое действие - это сценарий использования, поэтому это отдельный сервлет.

Answer 2

В большинстве веб-фреймворков используется сервлет-диспетчер (например, Spring MVC), который заботится о маршрутизации запросов к соответствующим классам / контроллерам.

Когда вы начинаете иметь много страниц, этот подход работает лучше всего, потому что у вас есть более удобный способ (в отношении web.xml) объявления / управления классом, который обрабатывает запросы http и его URL. Пример (опять mvc весны):

@Controller
public class MyController {
 @RequestMapping("/viewPosts")
 public void doViewPosts(HttpRequest r, HttpResponse res) {
  //...
 }
}

Кроме того, наличие сервлета-диспетчера обеспечивает централизацию потока кода.

Answer 3

Это зависит.

В моих последних проектах я реализовал один сервлет, который делегирует нескольким подобным сервлету объектам, которые создаются в виде внедрения зависимостей. Например, у меня есть что-то вроде этого в моем сервлете (псевдокод):

for(Handler handler : handlers) {
    if(handler.handle(request, response)) {
         return;
    }
}

где Handler - это интерфейс с методом логического дескриптора (запрос, ответ). Я получаю свои обработчики из контейнера (будь то Spring или что-то еще более легкое).

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

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