views:

1383

answers:

5

We have to create a web application for a school project and I'm wondering what best practices are when creating a web application using java servlets, beans and jsp.

Specifically I'm curious about servlets. Should a single servlet be created with many methods depending on which page is requested (a single controller) or should a servlet be created for each role of functionality?

Our application needs to have a public mode, user mode, and admin mode. Should a controller maybe be created for public functions and another for user functions?

I figured we should have a single servlet which all requests would go to, and that servlet would delegate to other servlets if required. Does this sound like it'd be the right approach?

A: 

Ask if you can use an MVC framework like Spring: which essentially has one Servlet acting as the gateway to the rest of the framework.

If you can't: I would say the less individual Servlets the better. You could create your own mini MVC framework and get one Servlet to pass control flow off to that.

You might also want to look at using Servlet filters for controlling access to various URLs based on role for your different user modes (another Spring idea, and very graceful).

JavadocMD
+1  A: 

I would recommend O"Reilly's Head First Servlets and JSP. But I'll give a basic rundown.

In general, you want to break your code up using the MVC pattern.

Your Model represents your data, your Controller is the Servlet, and the JSP represents your view.

Let's say you have a Vehicle. So you could have a Model called Vehicle.

If you want to say, get a vehicle, you may have a servlet GetVehicleServlet.

On doGet, you may gather parameters passed in and with that information, your servlet fetches the Vehicle data. Then, it will add that as a parameter to the request, then forward that request to your JSP.

In your JSP, you fetch the Model from the request attributes (or parameter, I forget off the top of my head) and render the display.

Thus, your JSP can display any vehicle information no matter where the data comes from as long as it is in the request.

This is a simplistic view though. There are many frameworks out there for managing the complexity of this, from Spring controllers, to Struts, to other things. I'll leave that up to other replies or your own research.

When I was starting out with Servlets and JSP, that book I listed helped a lot.

scubabbl
+1  A: 

Typically you have one servlet per page. The various methods of the servlet are used for different operations of the page, such as handling GET vs. POST.

The various modes should be determined by the user who is logged in. Store user information in the session. The controller should authorize the user, and redirect to an error/login page if the user does not have the rights to the given page.

Do not overuse the controller concept. A controller represents a page, not an operation, and not a user role.

Michael L Perry
A: 

I would avoid re-inventing the wheel. It sounds to me like you intend to create some sort of framework. In any case, you do not want to create a "God Servlet" from scratch.

You will likely want to use a MVC based framework. I have used Struts on many web applications and I have always been pleased with the results. I have been less than impressed with Struts 2 though.

Konrad
+5  A: 

Well, this is a school project, so I don't know if using a framework is the best idea. You might be better off just using the Servlet API, and then learning a framework on your own later and seeing why they are a good idea to use. If you haven't learned already, the idea of a single servlet handling all requests is one that was solved long ago by many different web frameworks. Probably the most popular over the years has been the Apache Struts framework, personally I prefer the more modern Spring MVC.

Whether or not you decide to use a framework or not, make sure that you keep the MVC design pattern in mind.

Also the application is divided into several layers on the server side. You'll have a web layer, which is generally classes that utilize the Servlet API (or use indirectly in the case of a Web framework). Generally you want to keep the web layer thin - the methods should only receive some request parameters and then pass them off to a Service layer, which would return some kind of domain objects. The Web Layer takes these objects and puts them in the proper web application scope (request? session?), and then forward off to a presentation file such as a JSP.

In the real world the Service layer will interact with a database, but it seems to me like you won't be using a DB but maybe have some business logic to worry about. The old paradigm was to put the business logic in the Service layer, but then you wind up with what is called an anemic domain model. Instead, keep object-oriented programming in mind and have your Domain objects be aware of the business logic.

In your JSPs, stay away from what are called Scriplets. Use the JSTL tags which are very powerful in their own right. Also if you find yourself repeating blocks of JSP or HTML code, investigate using reusable tagfiles.

It'd be interesting to see what you end up with and then have people offer their advice - wouldn't a website with online code reviews be cool?

bpapa