Сколько действий сервлет должен работать?

Никогда не следует передавать аргументы, чтобы указать сервлету выполнять различные действия. Все, что вам нужно сделать, это объединить 2 сервлета в один, и управлять этим становится все труднее. Вам понадобится сервлет для каждого «действия».

Вот один пример того, чего следует избегать:

/ App / Servlet1? Action = edit

if (request.getParamater("action").equals("edit")) {
//update fields

} else if (request.getParamater("action").equals("view")) {
//just query
}

Это может вызвать множество проблем, когда вы хотите переделывать что-нибудь. Вы захотите иметь отдельные сервлеты, потому что они отделяют вашу логику, чтобы вы могли легко ее изменить, а не связывать различные сложности кода, с которыми он не должен быть связан. Также см. Разделение проблем .

Исправлено / отредактировано: Я собираюсь сказать это сейчас (намного позже первоначального ответа) ... Вы можете сохранить концепцию "нескольких действий" и поместить ее в один сервлет (контроллер). Этот контроллер может и должен делегировать полномочия отдельным обработчикам действий. Я думаю, что то же самое с точки зрения разделения проблем И чище, чем мой первоначальный ответ. Другими словами, ничего не реализуйте в сервлете, используйте это только для маршрутизации.

Я предпочитаю меньше сервлетов, чем больше. Вы можете очень хорошо использовать сервлет в качестве единой точки входа, как и во многих веб-фреймворках. Один сервлет получает все HTTP-запросы, и на основе запроса выбирается правильное действие. Это базовый шаблон фронтального контроллера, который дает множество преимуществ, таких как возможность довольно легко создавать централизованные функции, такие как аутентификация и т. Д. Вот еще немного информации об этом: http://java.sun.com/blueprints/corej2eepatterns/Patterns/FrontController.html

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

If your web app is complex enough that the number of actions may exceed the number of servlets you are comfortable handling, then you might consider a web framework to abstract that problem away.

Your servlet layer should only do a few things:

1. Yank input from request
2. Manage session state
3. Dispatch objects to/from Business object layer
4. Push data into the response
5. Forward to a view
6. Handle errors/bad input/output

Almost anything else stuck into a servlet is a bad idea.

If you follow some simple guidelines, a simple servlet can call an input processor to turn data from the request and data that might be in the session into an appropriate object. That object can then be passes to a BizObject layer. That layer will return information that might be stored in the session and some object that will be passed to the view.

I used to enforce a 40 line rule for servlet service methods. If you went past 40 lines, I expected a good explanation.

I worked on an 80k line java web app that had two servlets, neither exceeded 40 lines. It handled about 60 forms/states.

At no point did I think it would be easier to manage/maintain/modify the app if more code were in the servlet.

Каждый сервлет должен иметь от одного до четырех действий, называемых doDelete, doGet, doPost и doPut. Эти имена соответствуют именам HTTP-методов DELETE, GET, POST и PUT. Вместе они создают RESTful API. Вы будете использовать всю мощь HTTP, если напишете серверный ресурс с этим унифицированным интерфейсом.

Чтобы получить RESTful API, подумайте о ресурсах как о существительных со стандартным набором действий. В итоге вы получите больше сервлетов (контроллеров), чем с фреймворком типа struts, но каждый сервлет имеет только ограниченное количество экшенов.

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