MVC Database Persistence – Where Should Database Persistence Code Sit in an MVC System?

mvc

I've seen multiple configurations for persisting information to the database. Generally, three types of designs seem common in my corner of the world:

Controller manages the persistence
Model manages the persistence
Third party library manages the persistence, usually requiring some sort of annotations on the model.

I'm wondering which configuration (if any) is, conceptually, the easiest to use/most compatible with an MVC architecture?

(If it's not one I listed, please give a quick outline/overview as part of the answer)

Best Answer

Your second and third options are identical. The M in MVC is not the data model, but rather the domain model. This includes persistence, whether done directly or via an ORM, and both are perfectly correct.

The controller should manage the flow of the site and passes stuff off to the domain (sometimes via a service layer) to be handled, so persisting from there is wrong -- or at least semantically uncomfortable.

Related Solutions

Php – Should PHP view files be called something other than ‘.php’

When you're talking about convention, there are a few bajillion different ways to do it. Ways I've seen:

index.tpl.php
index.phtml
templates/index.php
views/index.php

You can combine these methods to get some really amazing conventions!

views/templates/index.tpl.phtml

But if you ever do that you should feel bad about yourself.

The long and short of it - if you're using a framework, use their template convention. If you're doing it your own way, just be consistent, and, most importantly, if your template files are in web root and not named *.php make sure your webserver does not serve them as text!!!!!

Database Schema in MVC – Where Should the Database Schema Live?

No. Your SQL files either define your Schema or they define your data access.

The data retrieved from SQL files are not your model either, or rather database record sets should not be your model. There should be a level of translation that converts your record sets into data suitable for the Model.

In an ideal scenario your Model will be agnostic of data access logic and should mereley contain data that is pertinent to one or more Views as well as view state information as well.

Your Controller should bridge the gap between the View and the data contained in the Model such that only the Controller is concerned with data access matters.

On another note, if your SQL is NOT code then what is it? You are right to store SQL in version control because they define your application as much as anything.

Best Answer

Related Solutions

Php – Should PHP view files be called something other than ‘.php’

Database Schema in MVC – Where Should the Database Schema Live?

Related Topic