Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

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?

share|improve this question

3 Answers 3

up vote 3 down vote accepted

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.

share|improve this answer

how ... do you design your serverside application (in terms of layers) and what rules do you apply to them?

We use Apache, Django and MySQL. That defines the layers.

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

The justification is "That's the way Apache, Django and MySQL work."

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

Unthinking dogmatism is a bad practice.

Effort spent trying to "codify" or "reduce" architecture to a few rules is a bad practice.

What rules do you considered essential?

Architecture is hard.

Follow the simplest path that fits most closely with the framework.

share|improve this answer

Most of the time the layers and rules used are driven by the idiomatic usage of the base libraries and technologies you've chosen. The choice of base technology to use was hopefully made with some analysis and forethought. Occasionally you have to subvert the idiomatic usage, or even the base technology to get the job done. Those occasions should be rare because non-idiomatic usage is generally more costly to maintain.

Rules:

  1. Write the simplest code to implement the best solution you can in the most timely manner possible.
  2. Remove practices and techniques that make implementation slower, more buggy, and more complicated.
  3. Add practices and techniques that make implementation faster, more maintainable and easier.

These rules are often the justification for using certain architectures, technologies, or practices. The problem is that there are no practices that are applicable in all programming contexts.

Bad Rules:

  1. Treating any practice as sacrosanct.

No practice has value in and of itself. It only has value in it's ability to make you work "better". People often forget that and that's when you get dogmatic adherence regardless of cost or benefit.

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.