MVC Mindset

As anyone who follows my work knows, I have become very enthusiastic about working with API’s and learning more about their development.  I can envision a future where HTML, CSS, JS, and PHP are combined to a unified markup and scripting language that will power all display devices.  These devices still need data, however, so understand data architectures and how to access and work with data will become evermore important.  With this in mind, lets dive into an in-depth understanding of the MVC framework!

Models

The M in MVC stands for models, so lets start there!  Models are responsible for your data access.  They also control authentication and verification, but understanding them as data access routes will help simplify a nacient interpretation.

For example, the Laravel model User.php is a class that is responsible for the users of your app.  It does your authentication, it does your verification… it can hold a bunch of code but it all has to do with working with users of your app.  Models are representations of actual objects or entities in your application.

Models represent tables in our database.  Always use a singular name when creating models, and make sure they correspond to the table name in your database.  For instance, if we have a Users table, we need a view called User to interact with it.  Also works for irregular nouns, like a people table would be modeled by a Person class.  Notice how the table is plural but the model name is always singular.

Views

Views are the public display of your data.  They are the HTML and CSS that is used to make up the body of your webpage, then accept the data from the controller.

Routes

Views are managed by routes, which state the HTTP method to load the view.  For instance:

Route::get(‘/’, function () {

return View::make(‘hello’);

});

This is the default Laravel route.  The route gets the root page (‘/’), and when encountered, runs the callback which returns a file from the View folder called “hello.php”.  The .php can be omitted.

Remember, views should be agnostic as to the data or where it came from.  They just display what is sent to them, they have no control or guidance as to what is transmitted. The View simply renders information for public consumption.

Controllers

Conrollers are the moms of the app.  They don’t fetch information, they ask other classes to fetch the info.  Then, once received, controllers pass the data to views for public display.

Controllers are project managers.  They decide which pieces of data is needed, and sends that data where it needs to go.  Controllers also direct the routes.  A route is the URL and what is loaded when that URL is called.  Controllers create the URL’s and tell the routes what to load when that URL is called by the browser.

Controllers should be sending messages and configuring the server state, it is easy to force your controller to do too much of the logic, making your system less usable.

Remember: Fat Models, Skinny Controllers