Rails & 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.
MVC Basics
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.