Rails MVC and Routing Explained
Ruby on Rails is a framework that allows you to quickly build powerful web applications. Everything in Rails is designed to make the developers life easier by making assumptions about what is needed to start a web application. It allows you to write less code to accomplish many things.
There are a few principles that have guided Rails since it’s inception:
- MVC architecture
- Convention over Configuration
- DRY
MVC is an architecture that separates applications into three distinct parts.
The M stands for model. This is our objects. It encapsulates the data in our database and validates it. This is what really does the heavy lifting in the application.
The V stands for View. This is the presentation layer. It’s what the user sees and interacts with. The webpages, HTML, CSS, and Javascript.
The C stands for Controller. It processes and responds to events like user actions, and invokes changes to the model and view based on those. It makes decisions for us and ‘controls’ what happens.
Convention over Configuration is a set of defaults or assumptions as the best way to do things. Rails is designed to encourage this way of doing things and discourages alternatives. This way the developer can spend more time coding and less time setting up endless configuration files.
DRY is a software principle that aims to reduce repetition in your code and make it more maintainable and less buggy.
In the basic web architecture, we have a browser that interacts with a web page. Yes there is a web server in between them, but for the sake of simplicity let’s just look at the browser and page. This web page might have lots of code that would make decisions for us and finally output something back to the browser. It might even interact with the database. If enabled, the page can pull things out of the database and return that to the browser.
The MVC architecture suggests, instead of having this one page with many different things going on, we should break it up. The browser should communicate with the controller, and just the code involved in making those decisions on what should happen based on actions.
If we need to interact with the database, we will have the controller communicate with our model. All the code relating to the data and database connections will be in the model. The model can return its results back and forth to the controller.
When the controller is satisfied and ready to return results to the browser, it’s going to then send results to the view, the presentation layer. This will decide what HTML, Javascript, and CSS will get returned back to the browser.
Essentially we have taken that one page and broken it up based on its function. The controller handles the decisions, the model handles the data, and the view handles the presentation.
We must follow this architecture to keep our code in the right places. Decision code goes in the controller, data code goes in the model, and presentation code goes in the view.
Rails actually has names for these:
- Controller => ActionController
- View => ActionView
- Model => ActiveRecord
Rails packages ActionController and ActionView together as ActionPack.
Rails Routes
The routing is a crucial part of any application. If your browser did not have any Javascript, the only way a user could interact with your application is through a route.
The route is an endpoint that is put in the address bar of a browser. In a website url, everything after the slash is the only real way you interact with the application. Most of the time the user doesn’t type that into the address. They are clicking on a link or clicking a button on a form. And that is really just going to another endpoint.
It is also important to understand the anatomy of a route. A route is made up of a unique pairing of the method(http verb) and the endpoint itself. The route tells you which controller and specific action to trace to. Having multiple routes going to the same controller action is rare.
The controller action then always renders a view. This may not seem obvious because you never explicitly tell Rails to ‘render view’. It will choose where to render it instead by convention. The view will always outputs a new piece of HTML on your browser that will have other links that will go to other routes.
Rails also provides helpers. Form helpers or view helpers are commonly used terms. Helpers are a named Ruby methods that you call and will execute a block of code. These helpers get attached to the route, allowing you easy access to different pages within your code.
What is great about rails overall is that it’s going to provide pre-written software functionality for creating web applications. This generally makes it very easy to create common tools used in web development for database access, authentication, and templating pages. Many things that are otherwise complicated are very easy in rails. The fact that it’s written in Ruby makes it especially easier for newcomers to grasp.