Getting Code Organized

As my time in the developer community has grown along with my skill set, I've started making personal projects that are larger in scope. What comes with that is of course more code. As I continue to increase my knowledge and my search for an SWE role, I've sought ways how to better organize my own code. Well, during my prep I came across something called MVC. It's a real-world architecture that find might find on the job, so naturally, it would be nice to know what it is.

Model. View. Controller.

Right off the bat, I want to establish a brief definition of MCV and what it stands for.

MVC stands for Model View Controller, and is a way to organize code so that different sections serve different intentional purposes. In fancy terms, this is a popular architectural pattern used by individuals and companies, to divide related programming logic, into three distinct but interconnected elements.

Let's say you were working on an application that helped its users keep track of roles that they applied to during their job hunt. It might have some simple functionality like allowing the user to add the company of an applied role to a list. It might also allow a user to check a box when they have heard back from an opportunity. In our example, the Model would be how the code defines a "list", or the "check box". The View would be the part of the code that makes it look nice to the user. The Controller is the intermediary between the two, allowing the user to "check" the box, receiving the input and deciding what to do with it. It's the communicator.

MVC as a pattern mainly relates to the aspects of our code pertaining to user interface, so let's break it down just a little bit more to get a clearer definition of these concepts.

Model

The Model represents the underlying logic in an application. Containing pure application data, the Controller contains no information about how the application looks, only information on how it should behave upon being instructed.

View

The View represents everything in the interface that the user can see, respond to, or interact with. It is able to request information from the Model so that it can display the Model data to the user in the proper output

Controller

The Controller represents the classes used to connect the logic and the user's interface. Let's think about a user interacting with an application. As the liaison, the Controller interprets inputs such as a "click" from the user, and tells the model and view to change as necessary.

But Really, What's a Real World Example?

I'd like to take this opportunity to touch on some prior hospitality experience to elucidate this concept for you further. Let's say you were just seated in a restaurant. The waiter comes and presents you with your menu. Not knowing anything about you or what you'd like to order this evening, she writes down your order and hurries off to the kitchen. In the kitchen, the waiter does not prepare your food, but there is a chef who does. The chef knows how to prepare your food, unlike the waiter, but cannot do so without the ingredients which are held in the refrigerator. The chef dictates which ingredients to grab, the order he needs to incorporate the ingredients in, and how long he needs to cook them. The completed dish is then handed off to the waiter, who returns to your table so that you may eat!

In our lovely restaurant, the Model is represented by the refrigerator. The fridge holds the ingredients, or raw data, that the chef will use to make your dish.

The chef is the Controller. He has the understanding or logic needed to take the raw ingredients and "dish out" a specific output.

And that, makes our waiter the View, as she allows you to interact with the data in such a way that you get your desired dish and (have the best interaction of all) eat it!

Now (That We're Hungry) We Understand the Concept!

MCV is a great starting point for putting our ideas into code. Developers often create different folders within a project to help keep each of these objects distinct and organized. It allows for multiple developers to work simultaneously on a project easier, clean Separation of Concerns, and importantly allows easy code maintenance so projects can scale.

If you made it this far, thank you so much for reading!

As I get further into my coding journey, thinking about how code interacts with other code has become a major part of my thought process. I hope that this post will help you out in your understanding and guide you further along on your own journey as well! MCV helps promote coding with others, and in that spirit, I challenge you to reach out to someone in your network. Go over some LeetCode, start a small C.R.U.D. app, or just ask someone how they're doing. Coding together and learning together really helps to foster growth and the spirit of the coding community.