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.

Approach #1

  public class CustomerController extends HttpServlet {

    proctected void doPost(....)  {

            Customer customer = new Customer("xxxxx","23",1);
            new CustomerDAO().save(customer);



Approach #2

  public class CustomerController extends HttpServlet {

    proctected void doPost(....)  {

            Customer customer = new Customer("xxxxx","23",1);



 public class Customer {


   private void save(Customer customer){

        new CustomerDAO().save(customer);




Here is what a definition of Model is :

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 ?

  • 1
    The controller should load everything from the model and pass it to the view.
    – jgauffin
    Commented Nov 15, 2012 at 10:52
  • are you suggestion approach #2 ?
    – user65878
    Commented Nov 15, 2012 at 10:54
  • 1
    "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?
    – mefisto
    Commented Nov 15, 2012 at 11:05

3 Answers 3


In my opinion, you have to distinguish between the MVC pattern and the 3-tier architecture. To sum up:

3-tier architecture:

  • data: persisted data;
  • service: logical part of the application;
  • presentation: hmi, webservice...

The MVC pattern takes place in the presentation tier of the above architecture (for a webapp):

  • data: ...;
  • service: ...;
  • presentation:
    • controller: intercepts the HTTP request and returns the HTTP response;
    • model: stores data to be displayed/treated;
    • view: organises output/display.

Life cycle of a typical HTTP request:

  1. The user sends the HTTP request;
  2. The controller intercepts it;
  3. The controller calls the appropriate service;
  4. The service calls the appropriate dao, which returns some persisted data (for example);
  5. The service treats the data, and returns data to the controller;
  6. The controller stores the data in the appropriate model and calls the appropriate view;
  7. The view get instantiated with the model's data, and get returned as the HTTP response.
  • 2
    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?!
    – mefisto
    Commented Nov 15, 2012 at 17:22
  • 2
    @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.
    – sp00m
    Commented Nov 15, 2012 at 17:39
  • 3
    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 King
    Commented Nov 15, 2012 at 17:56

From model layer.

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 ?
    – user65878
    Commented Nov 15, 2012 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.
    – mefisto
    Commented Nov 15, 2012 at 11:02

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.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.