The model in an ideal world should only contain business logic, it models some real object such as a House. However in nearly all circumstances the model needs to persist its data to some storage.
Interactions between the model and the stored data can either happen on a separate data layer or directly in the model, which is the case when using an ORM (Object Relational Mapper). In other words either the model connects directly to the database or its passes its data to some other "data access" object which connects to the database.
An ORM (Object Relation Mapper) maps fields in the database table to the attributes of your model object, providing getters and setters. In this case there is no separate data layer and the model is directly responsible for persisting its data.
Here is an a Ruby example using ActiveRecord
a popular ORM:
class House < ActiveRecord::Base
end
house = House.new
house.price = 120000
house.save
Price
is a field in the houses
table which is automatically detected by ActiveRecord
which adds a getter and setter to the object. When save
is called the value of the price attribute is persisted to the database.
From my point of view the pro of having a data layer is that you get a point in which you can manipulate the data before it gets to the model, the model has less it worry about, it has less responsibilities. For example you may need to combine data from several none compatible data sources, this is something an ORM can not easily handle.
The main con is its another layer of abstraction to manage, if you don't need it, don't bother, keep it simple. Less moving parts, less to go wrong.
I'm not using the database as a simple object store
. I'm guessing that means some business logic in the database, in the form of stored procedures. In theory that goes against MVC, but in practice it doesn't matter.I want the data in the DB to have a life and meaning beyond the application.
What?