Rails and MVC
I often get into conversations with people who have explored the Rails framework, but for one reason or another haven’t gotten any further than a few simple online tutorials. As I explore a little further, the reason almost always boils down to two things: they haven’t taken the time to learn the ruby language, and they don’t fully understand the concepts behind MVC.
While the first is a little beyond the scope of a single article, I’d like to address the second.
Model-View-Controller (MVC) is a design pattern used in software engineering. In complex computer applications that present lots of data to the user, one often wishes to separate data (Model) and user interface (View) concerns, so that changes to the user interface do not impact the data handling, and that the data can be reorganized without changing the user interface. The Model-View-Controller design pattern solves this problem by decoupling data access and business logic from data presentation and user interaction, by introducing an intermediate component: the Controller.
The only problem I have with this description is that I often want to have this separation on applications that may not be very complex, and may not contain lots of data.
For anyone on board with web standards, the concepts behind MVC should sound all too familiar. Just as web standards seeks to separate content, presentation, and behavior, MVC seeks to separate data, interface, and logic.
The Model
The model is a representation of a piece of stored data, most commonly a database table. In the model we specify every requirement and calculation required to interact with this data, typically validation requirements, data relationships, create methods, update methods, destroy methods, find methods, and so on.
Any time you would write code that interacts with this data object directly, the code should go in the model. It can often be confusing determining if code belongs in a model or a controller, but my general rule is if you’re writing more than three lines of code in a controller method that interact with the same model, you could probably group those lines into a model method instead. This is most certainly the case if you’re repeating those same lines anywhere else in a controller.
The Controller
The controller is the logic between the model and the view. Controllers contain methods which directly correlate to actions performed by the user. The controller’s purpose is to respond to the action requested by the user, take any parameters the user has set, process the data, interact with the model, and then pass the requested data, in final form, off to the view.
Controller methods are typically short, small chunks of code that accomplish very specific tasks. If they’re more than nine or ten lines, than that should be a warning that you might be doing too much in the controller, and not enough in the model.
The View
The view is where the data, which was processed by the controller, gets output in the format requested by the user. In rails typically this will be html, but could be xml, js, json, or any other. The separation between controller and view is much more clear than the controller and model. There should be no output data in the controller, and there should be no data processing in the view.
In Conclusion
First and foremost, learn Ruby. If you’re looking for some impressive uses of Ruby, look no further than the Rails code itself. This is done most easily by running rake rails:freeze:edge from the command line, this will dump the Rails core code in the vendor/rails directory. Look through some of the code (don’t change anything!) and see how Ruby is being used. If you don’t understand something, look it up. Ruby has relatively good documentation, so dig in.
Second, make sure you have a good understanding of MVC. My descriptions here just scratch the surface, and are intended for the beginner. Once you have a good handle on MVC, then next thing to grasp is the testing process. But that’s for another article.
Post and Author Info.
Published November 26, 2006 by:
Commenting is currently off for this post.
So far there are 11 comments.
Welcome to the Rails, Steve. Just to recommend a few more resources for folks that are just starting out:
For a brilliant and quirky introduction to Ruby et al., look no further than “_why’s (poignant) guide to Ruby”: http://poignantguide.net/ruby/ You’ll be enjoying the chunky bacon, elven hams and sheer, unobstructed voltage in no time.
Let us not forget “The Pickaxe”: http://www.whytheluckystiff.net/ruby/pickaxe/ the free, online first edition of what is essentially a Ruby progammers bible.
Want to get a taste of the Ruby language, no commitment necessary? Then by all means, “Try Ruby”: http://tryruby.hobix.com/ Funded by an essentially lawful subsidy of _why the luck stiff’s grey matter.
Feeling a bit more confident? Don’t forget to mosey over and try out a quiz or three: http://www.rubyquiz.com/
November 26th, 2006
Good read!
I’ve just recently started exploring rails and it’s amazing. I love the structure along with the simplicity of use. As you said, this is merely an overview of MVC however it covers the important distinction of each layer.
November 27th, 2006
I know most everybody is enamored by Rails but I don’t see the point. I know PHP already so using MVC via CakePHP or Symfony seems a lot more prudent to me. I don’t mean to knock Rails at all, I just don’t see why it is worth learning an new programming language for. Am I missing something?
November 27th, 2006
Thanks. This actually helped a lot
- the reasons I never got into RoR were exactly what you said -I don’t know Ruby and I <strike>don’t</strike> didn’t understand MVC. Good read.November 28th, 2006
I’m one of those that played with ruby on rails quite a while back but never did anything beyond a few tutorials.
My reasons are different though. I already had built my own MVC framework I’d been using on PHP for several years. Rails was actually the first time I heard MVC coined, I had never thought of a name of it before, it was just my method.
I’m not sure why a lot of web developers don’t get MVC, it’s a natural extension of the platform itself. From when I first started doing web programming I saw that you had your datastore (database, file, whatever), action script (perl, php, asp, javascript… whatever,) and your output. There distinct and appropriately independent aspects of the overall program. Maybe it’s because a lot of the earlier web programming was done with tools that weren’t as modular, or people were still coming off of more procedural programming back from the DOS days and such, it’s hard to say.
November 29th, 2006
and then there are those of us who are proud if we are able to get something done in PHP or modify someone’s javascript…ignerint people…who just want to be able to get some feature going, and find they don’t know how, and don’t have enough time to learn a developer’s language from scratch. But probably those of us in that boat will have to. For example, I just want the effect of iframes in a Wordpress template for a client. So the whole page doesn’t refresh each time you click a link…so a multimedia piece can keep playing in the page while they browse. But it gets harder and harder to do these things, once you are working in a CMS package. Rails, Ruby, Ajax…I just want a frame! :-)
November 29th, 2006
Stefan and Shorty: Thanks. Glad it helped.
Alex: I think the reason many web developers don’t get MVC is they’re self-taught programmers. When using readily available web languages, like PHP, there’s no ‘standard framework,’ so people just end up writing a bunch of code in one page with SQL statements, logic, and HTML all mish-mashed together, just like old-school table-layouts with inline javascript and font tags.
Separation of these things takes time to learn, and might not come automatically to most people. And there may be some who are just starting, and need to get off on the right foot.
Coyotech: Are you sure you want persistant media on your site? Those always bug me to no end.
November 29th, 2006
I’m actually a self taught programmer, but I guess I got lucky in timing and taking an interest in compartmentalized/object oriented design styles!
I do understand the need to just “get things done” without attention to how. Throwing code in a page can be quick and effective. I just got bit in the ass too often when I was younger to be able to take that approach ever again.
November 30th, 2006
Adam H: If you don’t “see the point” of learning a new programming language, I can only assume that you only know one: PHP, and you don’t realize how different an experience it can be to work with different programming languages. The difference can be ginormous. And that is the point which you cannot see: that one programming language can be much better and much better suited for a particular kind of task.
PHP is, all things considered, a pretty shoddy language with a lot of quirks, hoops and inconsistencies. The primary reason for its success is probably the ease of deployment and short learning curve—not because it’s a great language, because it definitely isn’t.
December 14th, 2006
Tomas, you are spot on. I think the title “Developer” is so misused these days, it isn’t even funny. People who know a smattering of some language call themselves developers; people who know one language and see no point of learning anything else, call themselves developers. They aren’t, simply and bluntly stated.
Developers, true developers, seek to refine their craft, broaden their skills within their field, learn other languages because they see the benefit of learning a new thinking style. In short, developers consistently are learning and keeping up with technology. If you are going to enter the technology field and not keep up with what is going on and try learning new things, then frankly this field isn’t for you.
For far too long anyone who can write an includes statement or SQL statement has been calling themselves developers for simply being able to do just that. Well, one isn’t.
Developing is an art form that is constantly evolving at a rapid pace. Either you keep up with your craft or you become obsolete.
December 15th, 2006
Very nice overview of the MVC architecture. I also fully agree that learning Ruby should be a first priority before going too deep into Rails. It’s no coincidence that the framework has the programming language as part of its name. Personally I was first interested in checking out this “Rails thing” that got a lot of buzz. However, I fell so much in love with Ruby itself that I’ve hardly had time to work with Rails. And this is from a guy who have always been a firm believer in statically-typed languages – I still am, but I have seen in Ruby some of the major advantages of more dynamic languages. I only wish more research will be put into combining the advantages of both.
A weak point about Rails (and to a lesser extent Ruby) is unfortunately the documentation. It is often very poor, lacking in many places, and worst of all constantly out-dated. I think that may be a big part of the reason why a lot of people apparently catch an initial interested in Rails and then never get much further with it. I look forward to reading the 2nd edition of Agile Web Development with Rails and I hope it will solve some of the documentation problems with Rails.
December 26th, 2006