I have seen various arguments against the DAO being called from the Controller class directly and also the DAO from the Model class.Infact I personally feel that if we are following the MVC pattern , the controller should not coupled with the DAO , but the Model class should invoke the DAO from within and controller should invoke the model class.Why because , we can decouple the model class apart from a webapplication and expose the functionalities for various ways like for a REST service to use our model class.

If we write the DAO invocation in the controller , it would not be possible for a REST service to reuse the functionality right ? I have summarized both the approaches below.

Model:
The model manages the behavior and data of the application domain, responds to requests for information about its state (usually from the view), and responds to instructions to change state (usually from the controller).

In event-driven systems, the model notifies observers (usually views) when the information changes so that they can react.

I would need an expert opinion on this because I find many using #1 or #2 , So which one is it ?

"A controller can send commands to its associated view to change the view's presentation of the model (e.g., by scrolling through a document). It can send commands to the model to update the model's state (e.g., editing a document)." .. emm .. where does it say, that controller should be extracting data or passing it around?
–
tereskoNov 15 '12 at 11:05

What you call "life cycle of a typical HTTP request" is not MVC. And DAO is just an object, which facilitates interaction/translation between domain logic and persistence. It is NOT a different name for active record. Also .. since when model has become part of presentation?!
–
tereskoNov 15 '12 at 17:22

1

@teresko 1) Yes, it is MVC, but within a 3-tier architecture. If not, why? 2) You was right, I edited. 3) Since the whole MVC pattern takes place in the presentation tier. Typical example: Spring MVC, whose models are only Maps containing key-value pairs. SpringFuse has made this choice too.
–
sp00mNov 15 '12 at 17:39

I have to agree with @sp00m here... His description of a typical HTTP request is accurate for an MVC web app, and his positioning of the Model (as the 'M' in MVC) as part of the presentation tier is also correct. In n-tier MVC apps, the 'Model' is typically the presentation tier's facade over the rest of the tiers below.
–
Eric KingNov 15 '12 at 17:56

I'm not sure what the official MVC pattern calls for, but I normally like to have a "service" layer in between the controllers and the DAOs. The controller pulls data from the request and passes it to the appropriate service class. The service class is responsible for calling one or more DAOs that pass back model class(es). Those model classes are then sent back to the controller in order to be sent to the view layer. Putting the service layer in helps with reuse since multiple controllers can make use of the same service layer methods.

To be more precise: from services, which are contained in model layer, because they govern the interaction between domain objects and storage logic abstractions.

Controller should be only responsible for changing the state of model layer. DAOs are part of persistence mechanism. This constitutes a part of domain business and application logic. If you start interacting with DAOs in controller, you would be leaking the domain logic in the presentation layer.

To use a service layer , it should be DDD pattern ? correct me if im wrong. Do we have service layer in MVC ?
–
titoNov 15 '12 at 10:55

You can have. Services are used to separate the domain logic from the application logic. This becomes necessary, then you move from pure CRUD domain structures (active record), to something that separates storage logic from domain logic. In fully realized model layer you have 3 logical separations: persistence, domain and application.
–
tereskoNov 15 '12 at 11:02