1

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.

Community
  • 1
  • 1
Tony R
  • 11,224
  • 23
  • 76
  • 101

3 Answers3

2

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.

Community
  • 1
  • 1
BalusC
  • 1,082,665
  • 372
  • 3,610
  • 3,555
1

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.

duffymo
  • 305,152
  • 44
  • 369
  • 561
  • Thanks, although I don't want to use Spring. But if I was to do it this way myself, I could make an object that knows the relationship between processing objects and request URL's, and use it as the "dispatcher"? So, the "login" form would go to "www.mysite.com/Login", the "contact us" form would go to "www.mysite.com/Contact", both of which map to the Front Controller servlet, which uses the dispatcher to delegate these form requests? – Tony R Jan 23 '11 at 19:13
  • I didn't say "use Spring"; I cited it as an example to follow. Yes, you could write a FrontController servlet, ViewResolver and Controller POJOs, etc. But if you're going to do all that you might think about a web MVC framework - Spring's or Wicket or something else. Reinvent the wheel only if you wish to learn how wheels work. This is a problem that's been solved hundreds of times. What makes you think you'll do better? – duffymo Jan 23 '11 at 19:19
  • 1
    Haha thanks - I doubt I'll do better, but I like inventing wheels... It helps me understand things. – Tony R Jan 23 '11 at 19:52
  • That's fine - I would actually encourage everyone to do it at least once for themselves so they'll understand and appreciate what a web MVC framework does for them. That's exactly what you should do - until you get it. Then I'd find something that saved the boilerplate work for me. – duffymo Jan 23 '11 at 20:00
0

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.

Manidip Sengupta
  • 3,573
  • 5
  • 25
  • 27