Originally posted by Mark Spritzler:
You can even end up creating a Controller Servlet, that will hand it off to a class that determines who actual handles the Request coming in. Kind of sounds like Struts and JSF frameworks.
Or you could just use one servlet per request and have the web container, via <servlet-mapping> tags in web.xml do the work.
I am not a big fan of web frameworks mainly because when what I consider good practice is followed, they aren't really needed.
As suggested here, the 'front end' (web, swing, ejb, webservices, command line) module should only act as a fascade or translator to the actual meat of your app. Each of these should handle the protocol required to communicate as well as take the user's input and prepare/parse it into what the actual business methods require.
If all the web app is doing is getting some info out of the Application Context, Session, Request or Page, passing it off to a POJO that does the work and then forwarding to a JSP to show the results, I don't really think a framework is called for.
Like suggested, keep it simple. Total seperation of the logic from the presentation (Servlets & STRUTS are the bridge between View and Controller) will only make you a happy boy down the road.