Java Web Project Structure Best Practice

Question

Hi All

I am starting a new Java Web Project which is using Hibernate and a standard MVC Architecture. I have just started to layout the projects structure and while doing this I started to look around to see if there was any standards in this area, about where Controllers should go and generally the best way to lay everything out. However I have not really found any guidelines.

So what I am curious to know is

• Is anyone aware of any best practise guidelines for the layout of a Java Web Project?
• Does anyone have a particular set of hard rules that they always follow for different types of project?
• Do people tend to split packages by the different layers such as presentation, business, and application?

Many Thanks for your replies in advance

Answer 1

First, the to follow the conventional structure of a popular ide, ala Eclipse, Netbeans, etc. In Eclipse, for example, everything is arranged already with a WEB-INF and META-INF folders, so packaging and deployment is easy. Classes source code (typically under src) is automatically copied to WEB-INF/classes. There are a few other considerations:

1. If you are using MVC, then it is possible that you don't need to access your JSPs directly. If so, keep the JSP source code under WEB-INF/jsp, for security reasons.
2. Similarly, keep custom tag files under WEB-INF/tags.
3. Keep javascript files in js folder, css files in style folder, etc. All folders should be at the same level as WEB-INF to mimic a real deployment.
4. It is good to separate your code into packages according to layers. Obviously your Hibernate daos don't need to be at the same package as your servlets.
5. If you end up with too many servlets in the same package, consider sub-packaging them accord to functionality, but it is nice that they have a common ancestor package - it helps with readability.

Answer 2

To continue my previous answer, I have many web projects. In all of them the structure under src is more or less the same. The packages are roughly separated to 3 logical layers.

First is the presentation layer, as you said, for servlets, app listeners, and helpers.

Second, there is a layer for the hibernate model/db access layer. The third layer for business logic. However, sometimes the boundary between these layers is not clear. If you are using hibernate for db access then the model is defined by hibernate classes so I put them in the same area as the dao objects. E.g. com.sample.model holds the hibernate data objects and com.sample.model.dao hold the dao objects.

If using straight jdbc (usually with Spring), then sometimes I find it more convenient to put the data objects closer to the business logic layer rather than with the db access layer.

(The rest of the stuff typically falls under the business layer).

Answer 3

It really depends on your web framework.

For example if you use Wicket, java files and webpages co-exist in the same directory while in most other frameworks, pages (.jsp files or whatever is your presentation engine) and code-behind stuff (java files ) are completely separate.

So read the documentation that comes with your framework (Spring MVC, Struts, JSF e.t.c).

Another good proposal is to use Maven Archetypes to generate a skeleton for your specific framework. Some web frameworks (such as seam) have even their own code generation tool that lays the foundations for your web project.

My only good suggestion (that is not mentioned by Yoni) for the src directory is to make packages according to business purpose and NOT according to type/layer

That means packages for

• com.mycompany.myproject.customers
• com.mycompany.myproject.departments
• com.mycompany.myproject.billing
• com.mycompany.myproject.reports
• com.mycompany.myproject.admin

and NOT

• com.mycompany.myproject.entities
• com.mycompany.myproject.tables
• com.mycompany.myproject.graphs
• com.mycompany.myproject.dialogs
• com.mycompany.myproject.servlets

The second structure is too generic, tends to resolve around huge packages with unrelated stuff and is hard to maintain.