I'm trying to refactor my application into MVC, but I'm stuck on the M part.

In a database-backed app, the model is implemented in the app code, right?

But then, what is in the database -- is that not also the model?

(I'm not using the database as a simple object store -- the data in the DB is an enterprise asset).

  • 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.
    – yannis
    Dec 1, 2011 at 13:38
  • @YannisRizos -- there is BL in the DB, but what I meant by that is that I want the data in the DB to have a life and meaning beyond the application.
    – user39685
    Dec 1, 2011 at 13:42
  • 3
    I want the data in the DB to have a life and meaning beyond the application. What?
    – yannis
    Dec 1, 2011 at 13:48
  • 2
    @YannisRizos -- I would definitely appreciate help refactoring that statement. Data is an enterprise asset, right? It doesn't belong to the app -- so the app isn't allowed to create some crazy denormalized model that makes it very easy for the app, if that makes reusing the data from other apps very difficult. Any suggestions?
    – user39685
    Dec 1, 2011 at 13:51
  • 1
    That won't be an issue, if there is a format for anything existing that needs to be shared, then that becomes part of the requirements for storage format. Anything in the future that needs it in another format can have an ETL task, or transform it in the DAL.
    – StuperUser
    Dec 1, 2011 at 13:57

13 Answers 13


Yea, both the model in the code and database are the "Model".

The model has to do with what your application "IS", and the controller is what it "does". Any code dealing with direct persistence to the database is considered the Model.

Note: MVC is a pattern, so don't over-think it. It's easy to get all super into doing MVC the right way, but at the end of the day, it's just a mindset! It means keep your business logic out of the database and UI - that's it. Before MVC, people would put business logic all up in their webpages when it should be on the server, or they would have a bunch of scripts firing in the database doing business logic right along with the persistence code. MVC was brought about to get people to start thinking in a way that helps make their code reusable, so don't get caught up in the details too much.

  • 15
    So from the perspective of the C and V, that there is a database is just an implementation detail of M?
    – user39685
    Dec 1, 2011 at 13:48
  • Definitely. Nicely phrased.
    – herby
    Dec 1, 2011 at 13:52
  • 3
    @MattFenwick From the perspective of the C and V, there is no database. You are using the database as more than data storage, in MVC terms a database is only a data storage. But that's perfectly fine, if it suits your application.
    – yannis
    Dec 1, 2011 at 13:53
  • 5
    +1 for "don't overthink mvc"
    – Javier
    Dec 1, 2011 at 14:01
  • 2
    "keep your business logic out of the database and UI" - this Dec 1, 2011 at 17:28

Trygve Reenskaug wrote the initial papers describing the MVC pattern back in 1978. The Model in his description was the object model representing real world objects, phenomena, and concepts. In your scenario of a database-backed application, the model is a projection of your data. To put it simply, the model is the classes and their relationships that your application is concerned with.

In practice, there are usually two models used in MVC, the Domain Model (what's mapping to your database) and the Application Model (also called the View Model in today's terminology). The Application Model is a projection of the Domain Model that also contains view specific data for rendering the view. This approach is called MMVC. The controller directly interacts with the domain model and presents an application model to the view. In the MVVM pattern the Application Model and Controller are combined.

  • +1: I like this answer the best. The model is a projection of your data. The database is designed to store the data in the most efficient manner for accessing and indexing. The model should be designed around the business domain instead. Dec 1, 2011 at 14:54
  • Took me a second to parse the Domain Model (what's mapping to your database). Nice answer!
    – user39685
    Dec 1, 2011 at 15:46
  • 2
    +1 This is a great description of the different flavors that MVC has evolved into.
    – Ryan Hayes
    Dec 1, 2011 at 15:54
  • Thanks guys. I've been diving deeply into this stuff while writing my book. Glad it makes sense! Dec 1, 2011 at 19:35
  1. You don't need a database for MVC. If your model happens to talk to the database, then great. It could also persist itself to a flat file, or not persist itself at all.

  2. The model is where data is stored in memory in your application. You will also want to use the model to do calculations and validations on its data. For example, you have a FinancePayment model, with properties such as interest rate, term, and principle. You might add a getMonthlyPayment() method to your model to calculate the monthly payment. You wouldn't want to do that in the controller or view.

  3. The view should be reasonably dumb, either having no logic at all, or using only simple data binding (see Passive View and Supervising Controller patterns on Martin Fowler's site ). The view raises events when the user does stuff, like clicking a button.

  4. The controller is responsible for handling events (run some code when user clicks save button), and for setting model properties, and telling the model to load and save itself (if using persistence). The controller should not be doing calculations on the model's data. However, in the controller, you might do some calculations on behalf of the view, such as "if model.profit() < 0 then widget.colour = 'red'"

  5. You should be able to switch to a command line version of your application without changing the models, and without losing the functionality of the models.

a. You should probably be able to switch to a mobile version of your application (as opposed to a desktop version) by only switching the views (and not the controllers or models). You should be able to unit-test your models and controllers without a GUI testing framework.

  • Right on! This is very clear.
    – user39685
    Feb 29, 2012 at 19:28

Model is the code that has connection to V and C in the frontend, and to the persistent storage (can be anything from files to SQL/NoSQL databases) in the backend. It is not only the code that loads from db and stores to db (which is one of misunderstandings of the model), it is the code that actually does all the "domain" work - selects, filter, alters, computes, decides over the data. Includes all the non-UI logic of the application.

  • The raw data you want to have persistent. In any organization that fits best for your model. The model is an API that makes your application logic live. That database is the storage for the (non-living) data. If it is possible for your app (I don't know which kind of app it is), try stop to think of it as a "database-backed app", but just an "app", which uses a database as a way to persist module data. Many problems stem from "iconizing" the database - it is nothing more than a data storage for the model; you can ditch it, restructure it or replace it if it helps.
    – herby
    Dec 1, 2011 at 13:36
  • (above holds only for scenarios when data in db are not shared with another application)
    – herby
    Dec 1, 2011 at 13:37
  • I apologize for poor word-choice in my comment -- what I meant to say was that I'm not sure what's in the database, with respect to MVC. Is the database outside of MVC? Is it part of the model? Is it part of V or C (probably not, but you get the point).
    – user39685
    Dec 1, 2011 at 13:40
  • I see. You probably derived from my answer that you can see it a part of the model which serves to persist the application data which the code from the model processes. (I see the EDIT): If that database is something that must outlive the application, than look at the database as the external service, which model must communicate with, get data for computation and also send some back.
    – herby
    Dec 1, 2011 at 13:49
  • In the extreme case, when business logic is in the DB itself, you can have very thin model that mostly relays to the DB, or even say that db is your model (but then, it should have all the logic).
    – herby
    Dec 1, 2011 at 13:57

Taking a very simplistic and idealistic view.

The Model is generally seen as a model of the domain (roughly, the business), not as a model of the data. These may look similar, but they are not completely tied to one another.

The View should be a model of the application front end and the Controller should be a model of the flow from one view to another.

Business logic should be entirely encapsulated in the Model, whether it be in the database or code. Although some business logic may be repeated in the View or Controller, for various reasons, it should be possible (and safe) to remove those two components completely and put a different front-end in its place.


To my understanding, MVC is just the description of the architectural pattern of your client application. The picture here in Wikipedia just shows this:


Of course, when you have parts of you application implemented in "stored procedures", then those database code may also be part of the model, or even of the controller (depending what the code does). But if that's not the case, then the database is clearly "outside of MVC", just as you stated it.

But then, what is in the database -- is that not also the model?

No it is not. "The model manages the behaviour and data of the application domain". Often, the Model hooks into a database yes, but in no way is that a requirement. The model is a new layer between your application and the database. The backend could be a set of Mock objects, XML, or anything else that supports data persistence.

By decoupling the layers you give yourself much greater flexibility to use better unit testing practices, make the code more manageable (E.G. SQL gets replaced by Oracle) amongst other benefits.

The same goes with the controller. MVC defines the controller as a middle man between the two layers. There is no "business layer" defined in MVC. Rather, you add your own. MVC does not encapsulate all layers required to build most applications. It's just a general guideline for the basic structure.

These separations are key to allowing inversion of control to function.

  • +1 for an excellent and very informative answer; although, I'd suggest that the final sentence deserves elucidation. IoC isn't necessarily that widely known and understood, so it might add a tiny bit of confusion. A really useful explanation of what you mean by that is probably well-beyond the scope of a sane SE answer, but it did jump out at me. Dec 1, 2011 at 16:42
  • However, if you place your business logic in stored procedures, then yes, the database does encompass the model. (Personally, I would not recommend that approach.)
    – Roy Tinker
    Dec 1, 2011 at 17:57
  • 1
    @Roy Tinker - No, that does not matter. The model is conceptually separate. There will be entities that integrate with the database somewhere within the layer. These entities should remain decoupled from other entities that exist within the model that have other relationships (a Mock for example). The Controller should make it's calls to the Model in such a way that it has no knowledge of how and where the data comes from. Rather this determination should be made with dependency injection and IoC (basically its an interface that can be tied to different backends, mocking or a DB). Dec 1, 2011 at 18:07

The database is an implementation detail of the model. The model should be a full Domain Model and should combine data and process. The separation should be between difference concerns and not between a process and the data related to that process.

See also: http://martinfowler.com/bliki/AnemicDomainModel.html


It is very simple actually, "Model" represents the abstraction for the data interface. That is why:

  • Databases are regarded as part of the Model, but not the model itself
  • The Model's data can come from databases, files, web-services or even be mocked.
  • Model classes in MVC, HMVC or similar frameworks should store queries (see "fat model, skinny controller" principle [1][2][3])

And —if I'm correct— that's why when someone refers to models outside MVC context, that someone most likely refers to the structure of the data (i.e. schema).


I think the M contain some logic and store data into DB. The controller invoke which module would be execute and this module will execute logics and store data in DB(May be has persisent layer) and then this module return value to V.


The M(odel) in the MVC should capture the model of the business/domain in one single place.

That should ideally include business rules of the domain as well as it's structure.

The C(controller) sholuld ideally only concern itself with mediating the information of business model to the presentation (e.g. the View) and capturing user input from V(iew) to initiate changes in the state of the model.

Database layer only deals (or rather should only deal) with persistence of the state of the model at particular point in time.

As such it is not something that belongs to either Model or Controller part of the MVC pattern, but rather it is a completely separate concern which can be implemented implicitly by transparently persisting any change to the model (as a function of the facade, providing the interactions with your Model to the Controller) or as it's done more often than not, called explicitly by Controller after it has finished making mutations to the model.


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

house = House.new
house.price = 120000

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.


Yes you are right.

(Model View Controller)

An architecture for building applications that separate the data (model) from the user interface (view) and the processing (controller).

In practice, MVC views and controllers are often combined into a single object because they are closely related. According to MSDN

The controller interprets the mouse and keyboard inputs from the user, informing the model and/or the view to change as appropriate.

Check this diagram:

enter image description here

For example, the controller code validates a request for data and causes it to be returned in a view. View-controller objects are tied to only one model; however, a model can have many view-controller objects associated with it.

  • 4
    In practice, MVC views and controllers are often combined into a single object because they are closely related. If you are doing that, you are doing it wrong...
    – yannis
    Dec 1, 2011 at 13:57
  • Where's the diagram from? And where's the definition from? Please don't just copy paste stuff from the internet without proper attribution.
    – yannis
    Dec 1, 2011 at 14:16
  • @Yannis Rizos - He's quoting MS documentation. It's a bit out of context here, but they are saying non-web applications often have a coupling of view/controller, but web applications have a very clear distinction. This is probably one of the reasons you don't see MS pushing MVC for their windows apps (MVVM instead), just web-apps. msdn.microsoft.com/en-us/library/ff649643.aspx Dec 1, 2011 at 15:24
  • 1
    @P.Brian.Mackey I suspected MS was somehow behind this :P
    – yannis
    Dec 1, 2011 at 15:43
  • I've edited your answer to include the link @P.Brian.Mackey provided. It's perfectly ok to quote external sources, but you must include links to them. Also MVVM might be very similar to MVC, but it's not the same pattern. In MVC views and controllers should never be combined into a single object...
    – yannis
    Dec 1, 2011 at 15:49

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy