Один или несколько сервлетов на каждое веб-приложение?
Я знаю, это зависит от веб-приложения. Но в обычном случае, что вы делаете: один сервлет, который обслуживает разные страницы (например, автономное приложение с изменяющимся содержимым), или для каждой страницы отдельный сервлет.
Возьмем, к примеру, блог. Есть стартовая страница с самыми последними записями в блоге, просмотр статей для отображения одной записи в блоге и архив. Вы реализуете это с помощью трех разных сервлетов или одного, который отправляет функции. По крайней мере, большая часть материала является общедоступной, например http-заголовки.
Итак, каков ваш опыт, что работает лучше всего?
Ответы 3
Обычно вы создаете сервлет для каждого варианта использования. Сервлеты действуют как контроллеры для вашего приложения. Когда вы идентифицируете взаимодействие со стороны пользователя, реализуйте сервлет для управления этим взаимодействием.
То есть, если вы используете простой сервлет / JSP для создания сайта. Если вы используете структуру, такую как struts, вы обнаружите, что они реализуют шаблон фронт-контроллера и используют один сервлет, который принимает все запросы и пересылает эти запросы классам действий, которые реализуют фактическую логику пользовательского запроса. это гораздо сложнее сделать самому, но это хорошая практика ... это причина, по которой так много людей используют эти фреймворки.
Итак, краткий ответ: вы создадите много сервлетов для каждого веб-приложения, поскольку каждое веб-приложение будет предоставлять несколько вариантов использования.
[EDIT] Перечитывая свой вопрос, кажется, что вы используете термин сайт для обозначения страницы или просмотра. Опять же, это зависит от того, что происходит с этой точки зрения. Например, для отображения самой новой записи в блоге у вас может быть сервлет, который составляет список записей из базы данных для отображения. Если пользователь нажимает на запись, другой сервлет может получить эту единственную запись для просмотра и так далее. В основном каждое действие - это случай использования, поэтому отдельный сервлет.
@ Вечный, не совсем, я так не думаю. Сервлеты - это довольно низкоуровневые строительные блоки, и в течение многих лет разработчики приложений использовали более продвинутые платформы, которые работают на основе платформы сервлетов, но обеспечивают лучшую архитектуру приложения. Spring MVC, например, является одной из таких структур, которая во многом похожа на ASP MVC.
Большинство веб-фреймворков используют сервлет диспетчера (например, Spring MVC), который заботится о маршрутизации запросов к соответствующим классам / контроллерам.
Когда у вас появляется много страниц, этот подход работает лучше всего, потому что у вас есть более удобный способ (в отношении web.xml) объявления / управления классом, который обрабатывает HTTP-запросы и его URL-адрес. Пример (снова весенний mvc):
@Controller
public class MyController {
@RequestMapping("/viewPosts")
public void doViewPosts(HttpRequest r, HttpResponse res) {
//...
}
}
Кроме того, наличие диспетчерского сервлета позволяет централизовать поток кода.
По-разному.
В своих последних проектах я реализовал один сервлет, который делегирует несколько сервлетоподобных объектов, экземпляры которых создаются способом внедрения зависимостей. Например, в моем сервлете (псевдокоде) есть что-то вроде этого:
for(Handler handler : handlers) {
if (handler.handle(request, response)) {
return;
}
}
где Handler - это интерфейс с методом логического дескриптора (запроса, ответа). Я получаю свои обработчики из контейнера (будь то Spring или что-то еще более легкое).
Причина этого в том, что мне очень нравится внедрение зависимостей, и этого трудно добиться в сервлетах; и я действительно не очень хорошо себя чувствую с большинством фреймворков, которые обеспечивают внедрение зависимостей веб-компонентов - мне нравится простота сервлетов.
Если бы не это, я бы использовал несколько сервлетов, хотя есть компромисс; либо у вас есть огромный веб-XML с множеством (и множеством) отображений сервлетов, либо у вас очень сложный сервлет (если вы не используете что-то вроде моего подхода d-i).
Это новое изобретение колеса. Особенно удачным колесом является DispatcherServlet. Подробнее см. static.springframework.org/spring/docs/2.0.x/reference/mvc.h tml. Его интерфейс контроллера принимает запросы и ответы, как ваши «обработчики».
Я знаю MVC Spring - очевидно, что он повлиял на мой дизайн. Но у него есть много функций, которые мне не нужны, и он несколько сложнее. У меня это хорошо сработало, и я хотел реализовать его сам. Если вам подходит Spring MVC, обязательно используйте его.
Не могли бы вы подробнее рассказать о I have implemented a single servlet that delegates to several servlet-like objects which are instantiated in a dependency injection fashion. Приветствуется некоторый псевдокод, например, если у вас есть 4 разных сервлета B, C, D и E, как мне добавить сервлет A, который будет выделять задания для B, C, D и E.
Мои B, C, D и E не являются сервлетами, это экземпляры интерфейса, который очень похож на сервлет. «А» - это сервлет. Я просто сопоставляю все с A, A вызывает метод службы в одном из объектов, подобных сервлету. Это одна из функций DispatcherServlet Spring, вы можете проверить их исходный код.
Это что-то вроде шаблона репозитория mvc? как и в asp.net mvc, мы объединяем аналогичную функцию в один контроллер. так похож ли сервлет на эту идею?