CODEWITHSUNDEEP
javatomcatservlets
Tony R
Tony R

Reputation: 11524

How to organize my servlets?

I am looking at such previous questions as:
https://stackoverflow.com/questions/98334/creating-a-java-servlet-web-application
How many actions should a servlet perform?

There are answers in these threads that contradict each other; some people say use a servlet for each page, and other say use only ONE servlet for your entire app.

I have the same problem. So, how to I decide what my servlets will be? If I use a single (or a few) "Front Controllers," how do I parse the requests to delegate them to other objects? For example, if a single page has 3 different forms on it, how do I tell the difference between their requests? How do I tell the difference between forms and requests from different pages? Assign multiple servlet-mappings for each form + page? Look at the parameter names? URL-encode a "request-type" parameter?

So many ways to do things...

P.S. I'd rather NOT use a framework like Struts - I want to know the best way to do this using the Servlet API. I'm using Tomcat7.

Upvotes: 1

Views: 900

Answers (3)

Manidip Sengupta
Manidip Sengupta

Reputation: 3611

I have tried out both, and I do not use any canned framework (whether that is good or bad). My feeling is that different servlets are better when they are fairly independent and modular in structure, so you can take them offline for upgrade or maintenance. Using single servlet is better when you are dealing with synchronization issues, especially with a database. But then again, you are the best judge how to partition them. I use difference servlets when I know they will access a completely different set of tables in the db.

Upvotes: 0

BalusC
BalusC

Reputation: 1108672

First of all, homegrowing a single (front controller) servlet without adopting an existing one (e.g. Spring's DispatcherServlet, JSF's FacesServlet, Wicket's WicketServlet, etc) is quite a work. But you finally end up with simpler and better reuseable/maintainable business code. There are usually no multiple front controller servlets on an average webapplication. There should be only one.

It's hard to tell whether you really need one or not. If you after all have only 3 web forms (and thus 3 servlets) in your webapp and this won't ever change in long term, then it's probably not worth the effort to spend days on homegrowing a MVC framework or diving into learning an existing MVC framework. It's hard to tell where's the border. But if you can be certain that the webapp in question needs expansion and/or enhances in the future, then it's really better to adopt the MVC pattern (i.e. a single front controller servlet) right now than then.

At least, if you intend to homegrow, then you can find a lot of useful insights in this answer. But reusing an existing framework will end up to be much better maintainable since there's much more chance to find one who already knows the framework from top to bottom so that s/he don't need to learn another framework before being able to maintain your webapp.

Upvotes: 2

duffymo
duffymo

Reputation: 308743

Front controller is just the gateway into your app for HTTP requests. But that usually acts as a traffic cop to route HTTP requests to classes that know how to handle them.

Spring, for example, has a DispatcherServlet that maps Controllers to requests (usually by URL). The Controller used to be an interface, but now Controller POJOs can also be annotated.

The Controller interface has a single method: handleRequest:

ModelAndView    handleRequest(HttpServletRequest request, HttpServletResponse response)

It takes in HTTP request and response and returns a ModelAndView.

Upvotes: 1

Related Questions