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.

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);
            customer.save(customer);

    }


 }

 public class Customer {

   ...........

   private void save(Customer customer){

        new CustomerDAO().save(customer);

   }

}

Note-

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 ?

share|improve this question

migrated from stackoverflow.com Nov 15 '12 at 14:20

This question came from our site for professional and enthusiast programmers.

    
The controller should load everything from the model and pass it to the view. –  jgauffin Nov 15 '12 at 10:52
    
are you suggestion approach #2 ? –  tito Nov 15 '12 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? –  teresko Nov 15 '12 at 11:05

3 Answers 3

up vote 6 down vote accepted

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.
share|improve this answer
    
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?! –  teresko Nov 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. –  sp00m Nov 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 King Nov 15 '12 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.

share|improve this answer
    
To use a service layer , it should be DDD pattern ? correct me if im wrong. Do we have service layer in MVC ? –  tito Nov 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. –  teresko Nov 15 '12 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.

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.