How many actions should a servlet perform?

Question

Hi,

I'm new to web development and am just wondering about best practices for java servlets. Should each servlet perform exactly one action, ie a servlet for login, a servlet for registration etc, or should I look to combine similar actions by passing a different parameter to tell the servlet which action to perform?

Cheers

Answer 1

In Frameworks such as Struts there is one single servlet (although there could be multiple instances of it running). This servlet will handle requests for various URLs and pass them off the the relevant action handlers.

I only end up writing extra servlets for serving different content types such as an image rendering servlet.

Answer 2

It is up to you how the application to be developed.

Answer 3

You should never pass arguments to tell a servlet to do different actions. All you are doing with that is combining 2 servlets into one, and that becomes more difficult to manage. You will want a servlet for each 'action'.

One example of what to avoid is this:

/App/Servlet1?action=edit

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

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

This tends to cause a lot of problems further when you want to redesign anything. You will want to have separate servlets because it is decoupling your logic so that you can easily change it as opposed to coupling its various intricacies of code it shouldn't be related to. Also, look into Aspect-Oriented Programming.

Answer 4

I prefer less servlets and than more. You can very well use servlet as a single point of entry as in many web frameworks. Single servlet is receiving all HTTP requests and based on the request right action is selected. That's basic front controller pattern, which created many benefits like possibility to create centralized functionalities fairly easily, like authentication etc.. Here's some more information about that: http://java.sun.com/blueprints/corej2eepatterns/Patterns/FrontController.html

Having functionality in many servlets just complicates things unnecesserily. However keep in mind that you can also make quite a mess using only one servlet if you don't divide and manage your code well.

Answer 5

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.

Answer 6

Each servlet should have one to four actions, named doDelete, doGet, doPost and doPut. These names correspond to the HTTP method names DELETE, GET, POST and PUT. Together they build a RESTful API. You'll use the full power of HTTP, if you write a server resource with this unified interface.

To get a RESTful API think of resources as nouns with a standard set of actions. You'll end up with more Servlets (controllers) than with a framework like struts, but each servlet has only a limeted number of actions.

Many frameworks use the front controller pattern with a single servlet which dispatches a request to a controller or action. But framework controllers or actions tend to duplicate functionality of the servlet API. The servlet container is already a kind of front controller, which dispatches requests to a handler (a servlet).