Один или несколько сервлетов на webapp?

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

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

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

Ответ 1

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

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

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

[EDIT] Повторное чтение вашего вопроса кажется, что вы используете термин сайт для обозначения страницы или вида. Опять же, это зависит от того, что происходит с этой точки зрения. Например, Чтобы отобразить самую новую запись в блоге, вы можете иметь сервлет, который строит список записей из базы данных для отображения. Если пользователь нажимает на запись, другой сервлет может получить эту единственную запись для просмотра и т.д. В основном, каждое действие является прецедентом, поэтому используется другой сервлет.

Ответ 2

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

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

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

Кроме того, наличие сервлета диспетчера поддерживает централизованный поток кода.

Ответ 3

Это зависит.

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

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

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

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

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