Welcome to the Treehouse Community

Want to collaborate on code errors? Have bugs you need feedback on? Looking for an extra set of eyes on your latest project? Get support with fellow developers, designers, and programmers of all backgrounds and skill levels here with the Treehouse Community! While you're at it, check out some resources Treehouse students have shared here.

Looking to learn something new?

Treehouse offers a seven day free trial for new students. Get access to thousands of hours of content and join thousands of Treehouse students and alumni in the community today.

Start your free trial

PHP Enhancing a Simple PHP Application Refactoring the Codebase Separating Concerns: MVC

Separation of concern too hard?

I didn't get any part of separating concerns videos and tried to go over them again and again, i think its too advance for me. can someone make me understand in baby step about MVC and code in it via the example?

1 Answer

Justin Black
Justin Black
24,793 Points

Imagine you have a program which has been released. A customer comes along and offers to pay you for a enhancement to one of its features. In order to get the money, you will need to change your program to add the new feature. Some of the things that will influence what your profit margin is are:

  1. how much code you have to change
  2. how easy it is to make the changes
  3. how likely you are to break existing features that are being used by other customers
  4. how much you can reuse you existing model/architecture

Separation of concerns helps you to get more positive answers to these questions.

  1. if all of the code for a particular behavior of the application is separated out, then you will only have to change code directly associated with your new feature. Which should be less code to change.

  2. if the behavior you are interested in are neatly separated from the rest of the application it is more likely you will be able to swap in a new implementation without having to fully understand or manipulate the rest of the program. It should also be easier to find out which code you need to change.

  3. Code that you do not have to change is less likely to break than code that you do change. So splitting up the concerns helps you to avoid breakage in unrelated features by preventing you from having to change code that they could call. If your features are mixed up together you might change the behavior of one by accident while trying to change another one.

  4. If your architecture is agnostic to technical or business logic detail then changes to implementation are less likely to require new architectural features. For example, if your main domain logic is database agnostic then supporting a new database should be as easy as swapping in a new implementation of the persistence layer.

And this really is the best way that I can explain what Separation of Concerns is really about.

So, with MVC you have 3 main elements.

The Controller

The Controller manages the user requests (received as HTTP GET or POST requests when the user clicks on GUI elements to perform actions). Its main function is to call and coordinate the necessary resources/objects needed to perform the user action. Usually the controller will call the appropriate model for the task and then selects the proper view.

The Model

The Model is the data and the rules applying to that data, which represent concepts that the application manages. In any software system, everything is modeled as data that we handle in a certain way. What is a user, a message or a book for an application? Only data that must be handled according to specific rules (date can not be in the future, e-mail must have a specific format, name cannot be more than x characters long, etc).

The model gives the controller a data representation of whatever the user requested (a message, a list of books, a photo album, etc). This data model will be the same no matter how we may want to present it to the user, that's why we can choose any available view to render it.

The model contains the most important part of our application logic, the logic that applies to the problem we are dealing with (a forum, a shop, a bank, etc). The controller contains a more internal-organizational logic for the application itself (more like housekeeping).

The View

The View provides different ways to present the data received from the model. They may be templates where that data is filled. There may be several different views and the controller has to decide which one to use.

A web application is usually composed of a set of controllers, models and views. The controller may be structured as a main controller that receives all requests and calls specific controllers that handles actions for each case.

Justin Black Nice way to put it, now i don't understand the coding much as its 'model' is totally based on functions and i really don't get it as i think randy went too advance with base_paths etc making it super difficult and the videos seems too fast etc. How can i break it down

Justin Black
Justin Black
24,793 Points

To be honest, I went through the PHP courses on here just doing the tests. I didn't watch a single video so I don't know exactly how he covered certain topics or what was left out.

Justin Black Just any example would do. You know best, you can provide any example.