22

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)

Improve this question

5 Answers 5

Reset to default
14

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.

Improve this answer
4
  • 2
    I disagree to a certain extent. Concrete utilization of persistence is application logic and thus belongs in an application Layer and not in the domain Layer. The domain layer (containing the domain model) should be ignorant of persistence for the casual business program. The controller is an orchestrator. It can orchestrate (data-)services, the UI and the domain model.
    – Falcon
    Feb 13, 2012 at 17:50
  • 1
    @Falcon: While the controller should control when data is loaded from and persisted to the database, it is perfectly alright to have it tell the model to do so. Using an ORM (standard or roll-your-own) will usually mean telling the model to load/save which then delegates to the ORM. Another way could be to have the controller tell an ORM to load/save something passing it a model class to load (with selection criteria) or model instance to save. Either way, the actual loading/saving will be intemately tied to the model.
    – Marjan Venema
    Feb 13, 2012 at 18:39
  • @Marjan Venema: Yes, I agree, but the question is where that code should live. I strive to keep the model as ignorant of persistence as possible and only model the domain entities with their behaviours and interactions. Anything else will live in application layers (as it's an application of my model). Mapping information/data access is completely decoupled from the domain model and can also take care of versioning (upgrade/downgrade). The application of data access also lives in application layers (which contain services, repositories etc.)
    – Falcon
    Feb 13, 2012 at 19:19
  • @Falcon: Yes, that is a good way of doing it and is how I have done it in the past using separate mapping classes. However with the advent of extended RTTI (Delphi) and reflection (.Net and others), I have no qualms about using these in conjunction with annotation of the Business Object Model's attributes to get everything going and just use overloads of, code hooks into and/or specifically coded initialization classes to take care of database versioning.
    – Marjan Venema
    Feb 13, 2012 at 19:31
5

Realistically, MVC is mostly a UI implementation pattern, so the question is somewhat moot. However, there are really only two big-picture options. Your controller typically dispatches requests to load or save entities in your model using either 1) a service layer of some kind or 2) the Active Record pattern.

The service layer can take any of a number of forms, though my personal preference is to work with a repository abstraction for the aggregate root entities, the concrete implementations of which will either work with some sort of ORM, or a lightweight DAO, or an API for some non-relational store if that makes sense for the application.

The Active Record pattern means that your model has responsibility for persistence, although it usually means a base class of some sort manages the mappings to your store, so your model is not really that directly involved.

Basically, the controller dispatches requests to persist objects, whether that's a call to your repository, your UnitOfWork implementation, or the Save method on your entities. If you're using repositories, your model objects are persistence-ignorant.

Improve this answer
3

In a MVC ( model-view-controller) system, the model contain the data. So I believe, taht the database persistence should be in it.

Improve this answer
3

Most high-level MVC samples I've seen have a separate infrastructure layer which has the actual database implementation code (i.e. the specific calls to NHibernate, or EF or Linq or whatever your data layer is), while the "model" layer (often also the "Domain" layer) has the interfaces that define the data services.

Improve this answer
0

The standard practice in MVC is to include data structure and persistence in the M(odel) layer.

The model layer does not only include the classes (POCOs etc) you are going to use in your application. They include the repositories for those classes.

An example would be a repository where you have bunches of data classes instances, ie: 

Clients repository

AllClients()
RecentClients()
ClientByID(int id)

You will be able to organize your model domain way better, and also have access to your data through many ways, but still the data/model layer will be compact and robust

Improve this answer

Your Answer

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

Not the answer you're looking for? Browse other questions tagged or ask your own question.