Software Engineering Stack Exchange is a question and answer site for professionals, academics, and students working within the systems development life cycle. It only takes a minute to sign up.
Sign up to join this community
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).
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.
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.
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
the Domain Model (what's mapping to your database). Nice answer!
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.
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.
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.
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'"
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.
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.
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:
http://en.wikipedia.org/wiki/Model%E2%80%93view%E2%80%93controller
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.
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:
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
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.
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:
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.
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...
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?