Question

Should the model just be data structures? Where do the services (data access, business logic) sit in MVC?

Lets assume I have a view that shows a list of customer orders. I have a controller class that handles the clicks on the view controls (buttons, etc).

Should the controller kick off the data access code? Think button click, reload order query. Or should this go through the model layer at all?

Any example code would be great!

Answer 1

Generally I implement MVC as follows:

View – Receives data from the controller and generates output. Generally only display logic should appear here. For example, if you wanted to take an existing site and produce a mobile/iPhone version of it, you should be able to do that just by replacing the views (assuming you wanted the same functionality).

Model – Wrap access to data in models. In my apps, all SQL lives in the Model layer, no direct data access is allowed in the Views or Controllers. As Elie points out in another answer, the idea here is to (at least partially) insulate your Controllers/Views from changes in database structure. Models are also a good place to implement logic such as updating a ‘last modified’ date whenever a field changes. If a major data source for your application is an external web service, consider whether wrapping that in a model class.

Controllers – Used to glue Models and Views together. Implement application logic here, validate forms, transfer data from models to views, etc.

For example, in my apps, when a page is requested, the controller will fetch whatever data is required from the models, and pass it to a view to generate the page the user sees. If that page was a form, the form may then be submitted, the controller handles validation, creates the necessary model and uses it to save the data.

If you follow this method, Models end up being quite generic and reusable. Your controllers are of a manageable size and complexity because data access and display has been removed to Models and Views respectively, and your views should be simple enough that a designer (with a little training) could comprehend them.