Web Application Design – Best Practices for Server Side Layering

designdesign-patternsjavaweb-applications

A web application is often designed to be layered. Typically there would be a Repository (Dao) layer, a Service layer and a Control (web handling) layer. The Control layer uses the Service layer which in turn uses the Repository layer. Often you'll see the Control layer using the Repository layer directly.

Also quite prevalent is Services using other Services. Quite often all Services inherit from a base service class which will contain all references to all Repository components.

So my question is really how and why do you design your serverside application (in terms of layers) and what rules do you apply to them?

What are the generally accepted justifications for these layers and these rules?

What rules do you see that should be considered 'bad practice'?

What rules do you considered essential?

Have you tried anything new in this area that worked?

Best Answer

Warning long, rambling answer follows and I'm not really using 1/2 of the formal terminology that I should be (but that's OK, because someone will correct me!):

No Golden Bullet

I'll start by saying that I think each software architecture should be designed for the problem at hand. There is no golden bullet, silver hammer or one solution that fits all cases.

Overall strategy

Is to:

  • Decouple your components
  • Code to interfaces
  • Generally think about the separation of concerns
  • Think about who is calling your code for what purpose

Why are there patterns?

Design patterns (and therefore frameworks around them) emerge because they solve certain common problems.

However, a mistake that I think many Java developers are guilty of is to over engineer architectures, applying patterns left right and centre. They think about all sorts of exotic "What If?" scenarios. My advice is that although there are common patterns out there, don't just blindly apply them, make sure you've got solid reasoning for doing so.

Examples

1.) People have used MVC for years because it gives you flexibility to change either the model, view or controller without impacting each other (unless you want them to). So for example if I want to:

  • Change my View technology from JSP to JSF I shouldn't have to change my 'Dog' Model
  • Add a legs field to my Dog Model, I don't automatically have to add that legs field to my list of Dogs View, or change my Controller in order for a user to travel from list of Dogs View to a detailed View of one Dog.

2.) One of the reasons why Services have become popular because of the rise of multiple clients. So for example if I want to have a Java Swing client and a JSP client that both list the big Dogs in the system they can both call the same DogShelterService method List<Dog> getBigDogs();

Conclusion

There are lots more examples of patterns and why they came about (I suspect someone will give better examples than I did). I find using a BDD, TDD/ATDD approach (at least in terms of your thinking) helps clarify the design and where you might want to go for a formal design patterns and where simple code will do just nicely.

Related Topic