In this article, we’re going to learn a little more about the MVC, the system Architecture at the core of the Rails Framework for Software Development. Hopefully, by the end of it, you’ll know why working with a system architecture can make all the difference when developing an app. Every app is composed of many layers (connection, interaction, utilities, etc). For that reason, it’s important to define the layers that you’ll be using in your app and how they are going to communicate with each other before actually building it. The MVC architecture aims at giving us a well-defined design pattern to build our app upon, already establishing all the layers and connections between them. Model View Controller Described the first time in 1979, the MVC pattern is a high-level system architecture that can be used for an app’s global architecture as much as for a small part of it. It breaks the components of your app in three parts: the Model, the View, and the Controller. In the beginning, the MVC was developed to map the input, processing, and output of programs with a GUI (Graphical User Interface). The majority of OOP (Object Oriented Programming) applications can benefit from the MVC pattern. Using such a pattern will make the code more reusable and enhance the interface definition since each layer takes care of its tasks. In practice, if you need to change or implement a feature in your code at some point, this change/implementation would be much more flexible and straightforward with MVC, avoiding big changes and refactorings in your code. Understood… But how can I implement this in my application and become a better developer? We’re getting there! To elucidate this, let’s use the illustration below to map the MVC behavior. MVC’s components and their relations to each other. Let’s picture this scenario… We’ve built an app that has only one button. This button, when pressed, shows user data like name, email, and age. Now, let’s figure out the MVC structure of this app: For the , we have the user interface with a button and a table in which the user info will be displayed. View For the , we have the method show_user, that calls the database info on the user and sends it to the view. Controller For the , we have a User class that will generate a User table in the database (with each row of this database corresponding to a user) and retrieve an object of that class whenever asked by the Controller. Model Well done! Now that we have our structure, let’s move on to the user experience. When the user presses the button on the screen, the notifies the who triggers the show_user method. To display the user data, we need to create a User object to retrieve it to the Controller. View Controller Therefore, the Controller notifies the (the User class in this case) who gets the data from the database and returns the User object to the Controller. Model The Controller checks if everything is ok with that object, and, if so, output the result to the that updates to allocate the data of the User object on the table and display it for the user that pressed the button. View If you’re still having trouble to grasp the concept, fear not! It takes time to build a fair understanding of MVC architecture. To make it easier, we’ll now see a detailed explanation of each layer. Model This layer is responsible for manipulating the data that will be processed in the app. It’s good practice when developing an app with MVC, to allocate all the important data in this layer, creating one or multiple models. The model doesn’t have any explicit link with the user interface (View), which is used to present this model or even edit it. For example, assume that we have a Car Model that will be used to feed the View with data of a particular car object. We can store a lot of information in this object, like color, model, year of production and even the car’s mileage. We can store anything we want into it, but remember: the way this data will be displayed should not be addressed in the model object. For this, we’ll use the View layer. Notice that models are a bit flexible and its assignments might depend on the specific app that you’re building, but in most cases, the model should not bother with what will be presented in the View. The core task of the Model is to manipulate relevant data for the good functioning of the app. View This layer is responsible for displaying data for the user and enabling the user to edit, delete or change the data in some way when necessary. The View is the opposite of the Model. Here, our core task is to display data and ignore how this data is stored or processed. Once again, keep in mind that these definitions aren’t absolute and you might encounter special cases in which you’ll need to store some data in the View, but rest assure that this isn’t the common convention. The View must make sure that it is displaying the Model object correctly. As a consequence, it will need to know when the object is edited or deleted. Since the View and the Model layer don’t communicate directly, we need a middle man up to the task. This middle man is called Controller. Controller This layer is responsible for intermediating the communication between the View and the Model. In our scenario of the one-button app, the Controller would be notified by the View when the user pressed the button. That would trigger a Controller method that would request data from the User Model, retrieve that data and update the View with it. The Controller is the manager that keeps everything in place. When all the communication between the View and Model are set trough the Controller, you make your code more reusable, recycling methods that can be used to set communication between multiple pairs of Views/Models. Note for beginners… This article only scratches the surface of the topic. To fully grasp MVC, you’ll probably need to research more about it and get your hands dirty and learn through experience (the most valuable kind of learning)!
