Question

I am trying to confirm whether this statement is true:

Model includes both:

persistence layer: essentially DAOs + classes representing tables + DTOs

service layer: Combinations of DAOS + some logic

Could you also please reference/support your answer? I believed I’ve seen in Spring Framework good diagram, but no matter how searched this time I can’t find it.

And the other point: I was always wondering why we abstract stuff so heavily that at some point people just stop understanding, is it done to increase our own value? :\

For example analysing Spring MVC I can say that central piece is controller no matter how you name other layers it is Controller who decides where to go what to extract , how to validate it and which view/controller to pass it on. Yet this simple statement is never found in formal articles keep confusing people.

So Controller is our god. Controller asking for some method within a class that call methods of another class. On top of it all is wired with dependency injection as we only need a single instance for objects of singleton nature. Controller>Service>DAO that’s it .I would really appreciate book written by pragmatics.

If people would write books based on how things really are and not how to make look them beautifully drawn in diagrams or written the endless questions as such would never raise in a first place. And I thank stackoverflow for people that always show me the path. 😉

Answer 1

MVC and the DAO/Service architecture are less concepts which are contained within each other than which sit next to each other.

In MVC, your controller takes care of fetching all the data, placing it in a model in some way, and passing the model to the view to be rendered. If you are also using DAO/Service architecture, your DAOs/Services might return an entity which contains all the information you will be displaying on a given page, and people often use these as the model for the view if things are relatively simple.

The problem with this tactic is you end up having dependencies between your views and the specific implementation of your model. Also, if you later decide you need some extra information which is not included in your model, you’ll have to rewrite your view to account for this. This is why it is often suggested you do as much preparation of your data in your controller before passing a very simple model (a Map) to the view.

Here’s a diagram showing the separation of layers: