MVC: Data Served Right

As my cohort with the Flatiron school pushes onward, we’ve come to a point of our learning where we are all feeling like real developers! I know I am. In my cohorts progression we’ve each built up a small web app with Sinatra. The process has been fascinating. Building up the layers to Sinatra with SQL, ActiveRecord, Rack, etc. seemed like a lot of pieces that made sense, but didn’t quite fit together until we synthesized them with in our Sinatra app.

Within the Sinatra DSL, and other web app frameworks such as Rails, the Model-View-Controller (or MVC) paradigm is used to maintain code separation by function. MVC allows us to read, write, and debug code in a much clearer format and makes the experience a lot less of a headache by providing us with a separation of concerns. This means that the files you’ll be creating in your app will have specific jobs and interact in defined ways. Much like a restaurant’s business flow between the chefs, waiters, and food delivered to the customer, all of these roles are seperate, but essential to functionality of the restaurant.

The Models of MVC will handle the logic of your application. Your models will be where data gets manipulated and/or saved. Models provide an object-oriented metaphor for the data you’ll be working with in your app. Your models will be the structures of your app that are talking to your database (were our data is persisted) by requesting certain data and using that data to create new instances of that model’s class. You can then interact with these instances using the methods and properties of that instances class. Our models will never be visible to the client using our app! Think of the models like the chefs in our theoretical kitchen. The chefs won’t interact with the customers, but they receive orders from waiters and create a product to meet the request using resources from their fridge/stockroom (the database).

The Controllers of MVC are the main interface for app logic. They are the go-between for the Models and Views. Controllers are classes that inherit from Sinatra::Base which gives your class a Rack compatible interface. Within your controllers you’ll define HTTP methods using the Sinatra routing DSL that provides methods like GET and POST. You can imagine the Controllers like the waiters in our restaurant analogy. They take the requests made by the client to the chefs to work with and then deliver the products of those requests back to the client as their meal (the View!).

Our MVC Views are what the client will see and interact with! The Views contain the front-end or “user facing” elements of your application. Views are generally written in languages like HTML, CSS, and JavaScript. The Views get rendered by the Controllers to be presented to the client. As you’ve probably noticed our Views are like the final dish served to the customer in our analogy! The customer/client places orders with the waiter (Controller) and receives the Views back as their finished order (which has been processed behind the scenes by the chefs/or Models!).

Coming from a decade or more working in restaurants and food service jobs and jumping into coding, I really liked MVC because of this common analogy! My former job experience made the concept really digestible to me and I hope that I have provided you with some clarity on MVC roles and functionality. It’s truly a fascinating system, so have fun creating your next big (MVC incorporated) app!

Student currently studying with the Flatiron School’s software engineering bootcamp.