23

I'm new in this, so bear with me. I've been using one MVC framework in a couple of projects lately, and after a while, I'm disillusioned in the perceived usefulness of the 'Model' in MVC.

I get the usefulness of Controllers and Views, I know that separation between presentation and logic is important to make the code more maintainable in the future, although not necessarily faster or more robust.

If all logic should be placed inside the controller in the first place, I don't see any use for Model, especially the Active-Record. We already have a language that is so robust and easy to use to communicate with the database, am I right? It's called SQL. For me when models are implemented like active-record, it's usefulness depends on whether or not you want your app to fit in multiple databases.

So what I'm asking is, if you're only using one database, why bother with Models and Active-Records? Why don't just use SQL? Why the extra layer of complexity? Do you guys have any case studies/real-life stories where models actually can do things better than just using the database class and SQL-away?

Again, I'm sorry if I seem to be so ignorant, but I really don't know why Models are important. Thanks for answering.

rickchristie
  • 1,640
  • 1
  • 17
  • 29

5 Answers5

21

First, you are assuming that a model layer necessarily uses some kind of ORM, in order to abstract SQL away. This is not true: you may create a model layer which is loosely-coupled from the Controller layer but tightly-coupled to a particular DBMS, and so avoid using a full-featured ORM.

There are some ORM libraries, like Hibernate (Java), NHibernate (.NET), Doctrine (PHP) or ActiveRecord-Rails (Ruby) that really can generate all actual SQL statements for you; but if you think ORM is unnecessary, and you want to define all SQL statements by hand, don't use them.

Still, IMHO this does NOT mean you should just place all you DB related logic inside the controller layer. This is called the "fat controller" approach, and it is a road that leads, many times, to bloated, unmaintainable code. You could use it for simple CRUD projects, but anything beyond that will demand the existence of a real "Model".

You seem to care about MVC. Please, read also something about TDD. A wise man once said "legacy code is code without tests". When you learn that automated unit tests are as important as the "real" code, you will understand why there are so many layers in an enterprise application, and why your Model layer should be separate from the Controller. A block of code that tries to do everything (presentation, business logic, data persistence) simply cannot be easily tested (nor debugged by the way).

Edit

"Model" is a little bit fuzzy term. Depending from where you look at, it can mean something slightly different. For instance, PHP e Ruby programmers frequently use it as a synonym to an Active Record, which is not accurate. Some other developers seem to believe that a "model" is just some kind of DTO, which is also not right.

I rather use the definition of model as seen in Wikipedia:

The central component of MVC, the model, captures the application's behavior in terms of its problem domain, independent of the user interface. The model directly manages the application's data, logic and rules.

So the Model is the biggest, most important layer in most MVC applications. That's why it is usually divided in sub-layers: Domain, Service, Data Access and so on. The Model is usually exposed through the Domain, because it's there where you'll find the methods that your controller will call. But the Data Access layer belongs to the "Model" too. Anything that is related to data persistence and business logic belongs to it.

bwegs
  • 3,769
  • 2
  • 30
  • 33
rsenna
  • 11,775
  • 1
  • 54
  • 60
  • Thanks for the answer! I think I understand more now. You mentioned a '.. demand the existence of a business layer' - this business layer, is it the Model? – rickchristie Feb 23 '11 at 17:35
  • Thanks for enlightening me - read about TDD - seems awesome. Will discuss with my friends. Starting today, my programming practices will change :) – rickchristie Feb 23 '11 at 18:32
9

In most real-life situations, data that comes from the user doesn't go straight into the database.

It must often be validated, filtered, or transformed.

The role of the model layer is usually to make sure that data arrives properly into the backend store (usually the database) by performing these operations, which should not be the responsibility of the controller (skinny controller, fat model), and not the responsibility of the database engine itself.

In other words, the Model layer is responsible - or `knows' - how the data should be handled.

Most modern MVC frameworks provide ways to specify contracts over the data validity requirements, such as Rails.

Here's an example from http://biodegradablegeek.com/2008/02/introduction-to-validations-validation-error-handling-in-rails/:

class Cat
  validates_inclusion_of :sex, :in => %w(M F), :message => 'must be M or F'
  validates_inclusion_of :vaccinated, :in => [true,false]
  validates_inclusion_of :fiv, :in => [true,false]
  validates_inclusion_of :age, :within => 1..30
  validates_each :weight do |record, attr, value|
      record.errors.add attr, 'should be a minimum of 1 pound' if value and value  /^[01][0-9]\/[0-9]{2}\/[0-9]{4}$/
  validates_length_of :comment, :allow_blank => true, :allow_nil => true, :maximum => 500
end

Here, several of the data validity requirements cannot be handled by the database, and should not be handled in controllers, because any modification in those requirements might break the code in several places.

Therefore, the model is the best place to make sure data is coherent for your domain.

There's a lot more to be said about it, but I felt like tackling a point that seems important to me, motivated by practical experience :)

SirDarius
  • 41,440
  • 8
  • 86
  • 100
  • Thanks for the answer! I always put data validation in my controller, is this a bad practice? In my framework, the validator class is separate with the model class - the validator class itself was written to be specifically used inside a controller. So is the Model implementation of the framework I'm using false? – rickchristie Feb 23 '11 at 17:20
  • You are saying that validation/data requirements should be handled by the Model, but in truth, many applications have data requirements that are actually based on a business rule (e.g. do not allow this member to purchase more than 2 iPads in a year). If I understand you correctly, using your example, this business rule will be written in the Model and not Controller, is this a good MVC practice? – rickchristie Feb 23 '11 at 17:23
  • 1
    That's right, as someone said in another answer, business logic should belong to the Model layer. Then again, the borders between those layers are quite blurry, and some implementations will prefer not adhering to the skinny controller/fat model paradigm. – SirDarius Feb 23 '11 at 17:33
  • Thanks! The way I understand it now, based on this answer and @rsenna's answer, is that using Models create a centralized pathway to update/insert/delete your data, and thus 1) make it easier to unit test 2) reuse validation, not only data-type constraints, but also business rules 3) since it's centralized, any change in the business rule would be easier to apply - is this correct? – rickchristie Feb 23 '11 at 18:00
8

It's not an ignorant question at all! Just the fact that you're asking it instead of simply ignoring the whole MVC theory and doing as you please is nice. :-)

To answer your question: conceptually, Models simply provide a nice abstraction for your data. Instead of thinking in terms of "how do I write this inner join to get all the fields I need", models enable you to think in terms of "how are my application's objects related to each other, how do they interact and how can I get the data I need from them".

In the same way that Views and Controllers help you seperate presentation from logic, Models help you seperate the application's logic (from a user's perspective, anyway) from the gritty details as to where your data actually comes from and how it's represented internally.

To give a more specific example (if not completely realistic): in theory, you could write your whole application in a way you fetched all the data through SQL queries. But later you realized you wanted to use some noSQL (CouchDB, etc) engine because you needed horizontal scaling.

With models (and a framework that can use both types of storage, of course :-)) you wouldn't have to worry about the details, as all your important data is already represented in a generic manner through your models and both views and controllers can act upon that representation.

Without them, you'd probably have to rewrite a large chunk of code just to adapt your data fetching to the new backend.

And that's just on the boring storage part. With pure SQL, it's much harder to define the interactions between your application's objects (i.e. the business logic) because you just won't do that in SQL (probably, anyway).

It's not a perfect explanation (far from it), but I hope it helps.

João Neves
  • 937
  • 1
  • 6
  • 13
  • Thanks for the answer! Is it safe to say that if our application does not require the usage of another database (if we are not expecting to change database or use more than one) - the usefulness of Model is reduced? If I understand you correctly, then using Model would be a risk-mitigation action programmers do, 'just in case the client requires us to change backend'. – rickchristie Feb 23 '11 at 17:26
  • 1
    In that case, it is only marginally reduced. The benefits of models, specifically, the benefit of being able to abstract away the implementation details and focus on the actual logic usually far outweighs all the others. If you simply start dumping SQL everywhere, you'll probably end up writing much more contrived code since you'll have to map all that data somewhere your controllers and views can easily use. From my experience, you'll eventually feel the need to do something that in essence is a model for your objects, even if you don't realize it at first. You might as well do it anyway. :-) – João Neves Feb 23 '11 at 17:34
3

The models should contain all your logic. The controller is only responsible with logic related to user interaction. All the domain-related functionality (what's known as "business logic") should be placed in the model and decoupled from controller code. Like this you can achieve a better separation of concerns and code reusability.

For example, let's say you are writing an application to let users enter information about themselfs and receive diet recomandations.

One the one hand, you would put code related to transforming user provided data into a list of diet recomandations in the model part. This includes database access, but also any calculations , algorithms and processing related to the problem in question (the problem domain).

On the other hand, you put the code to log the users in, show a form, gather the form data, validate it, in the controller. This way for instance you could later add an api to your app (which uses different code for authentication, getting data from the user, validation etc.) and reuse the code to generate the results (from the model).

This is just an example of what the model is good for.

matei
  • 8,465
  • 1
  • 17
  • 15
1

I always relate Model to data irrespective of where it is present or how it is represented. In MVC V displays data and C handles change. Even if you have all the data to be presented on the screen in a HashMap inside your controller; that HashMap will be called the Model.

Vinod R
  • 1,218
  • 10
  • 13