This is the first post of a RAILS series directed at Flatiron students.
Congratulations!
You've just finished mod 1. Well done.
You've crushed enumerables into your brain, built your first CLI app, and now you're being introduced to a totally new topic called Rails. Woah.
First, let me say this. It's going to be stressful and it might feel overwhelming but we'll get through this. For now, let's take a deep breath.
I'll give you a moment.
inhale
exhale
Ruby on Rails is a wonderful and "magical" framework that allows developers, like you, to rapidly build massive applications. For example, Github & Airbnb both use Rails in their stack.
Here’s a link to 34 companies using rails. Just like how active records simplifies some methods for us, Rails does as well. Today, I'll be teaching you one aspect of it: MVC.
Model, View, and Controller Architecture
Model, View, and Controller, MVC, is a way to have a separation of concerns amongst components.
What does this mean?
"Separation of Concerns is achieved by encapsulating information inside a section of code that has a well-defined interface. It is easiest to think of in terms of modularity."
This is a great way to say the model, view, and controller deal with their own problems and methods. Model problems deal with model problems, view problems deal with view problems, and controller problems deal with? You guessed it. Controller problems.
You're dividing the work of an application into three separate systems. Why is this good? It allows developers to easily identify problems, test methods, and scales as your application grows.
Model
The model component deals with data-related logic. It handles the relationship between the data and databases, validations, and associations between models.
Think about when we kept our data in our methods class. Now we keep data in our db and our class methods in a model.
Note, how would you get that all the way a user? Most would and should not need to know about all that information in the backend.
In our example, we'll call the model a barista.
View
The View presents the model’s data to the user. The user can see the data and the pretty layouts but when they want to modify layout or content, they're actually using a controller that communicates to the model.
The view is the counter where you see the menu and order your goods.
Controller
The controller is a link between your views and your model. In Rails, the controller handle requests from the users and communicates to the model-based off on the type of request made.
This will be the cashier!
Putting it all together.
Let's take an example of you entering a coffee shop.
You, self.name, enter a coffee shop and walk up to the counter(view) to order your coffee. You browse the menu at the counter (view) through a list of things you can order. You can view desserts, sandwiches, and coffee.
The cashier greets you with a warm welcome.
"Hello, I'm Nate, your controller what can I do for you?
drip? Nah.
Ooo, do I want a pour-over? Had that yesterday
Hm... I know.
"One americano, please.
Nate, the cashier/controller, receives your request and yells "AMERICANO" to the barista(model) in the back. He just told the model what to do and then smiles back at you asking "anything else?"
no, I'm good.
You, AND the cashier, don't need to know that that a good espresso needs 9 bars of pressure, 30 pounds of pressure on a 51mm diameter tamper, and should hit a ratio of 36ml to 25seconds for a proper extraction.
The barista(model) alone holds all that coffee-related knowledge.
The cashier(controller) is simply routing your request that you made at the counter(view) to the barista(model).
You, as the end-user, just want good tasting coffee to push you through another lab.
How does the barista(model) know what to make? By the cashier (controller)!
Now, the barista(model) has just finished your coffee. Are you going to go behind the counter and grab the coffee?
You can...but you'll probably also be banned from the shop.
Nate, the controller, will grab that americano and hand it back to you at the counter.
Voila! You've just experienced an MVC framework.
You made a request for an americano to the cashier(controller). The cashier just routed the specific request to the barista(model) who used their deep knowledge of coffee-brewing to make you a specific kind of coffee. They could have made you any type of coffee.
Affogatos, cappuccinos, macchiatos, and just about anything else! However, because they were given specific instructions by the cashier, the barista(model) made the americano that you requested.
After creating the americano, they hand it to the cashier/controller and they hand it to you back at the counter.
Here’s a quick diagram to wrap up what happens!
There could have been plenty of errors here.
The barista may not have known how to make an americano. That'd be a problem with the model.
The cashier may have had no idea how to process your credit card. That'd be a problem with the controller.
You may have asked for something that's not on the menu. That'd be a problem with you. (no offense)
With the MVC framework, problems and solutions are easy to identify.
I'll continue discussing MVC and increase the specificity over the next few blog posts! Comment below any questions and concerns you may have.
Icons made by ultimatearm from www.flaticon.com
Top comments (1)
Nice blog Nathan!!!