Class 10 – An MVC Social Network Example
Let’s say that we are building a social network. What we call a social network is a site that has a bunch of users, and those users can decide to be “friends” with any other user.
You can view this example live here.
The Views
There will be four pages that the user sees:
- Register – where new users go to register to become members
- Login – where registered users go to login
- Home – a page that shows a list of the logged-in user’s friends, and a list of people who are not his/her friends.
- Friends’s Profile – a page that shows details about another member
Each “page” requires a View in order to be displayed to the user in the browser. Anytime there is something displayed to the user, we should know that there is at least one View used to create that interface. So we can say that there are four Views in this application. In our example application, the files that contain the templates for these Views are:
- views/register_view.php – the template for the Register page
- views/login_view.php – the template for the Login page
- views/index_view.php – the template for the Home page
- views/profile_view.php – the template for the Friend’s Profile page
The Controllers
- We only want to let a user go to the Login page if they are not already logged in. If they are already logged in, we need to redirect them to the Home page. Anytime we have a script that performs some logic like this, we should consider it a Controller.
- Likewise, a user should only see the Register page if they are not already logged in. Again, this logic is handled by a Controller.
- Assuming a user is not already logged in, when they enter their username/password in the form on the Login page and click the submit button, there has to be some script that performs the logic to compare the username/password data the user entered in the Login page to the user data stored in the database. If the username/password matches what is found in the database, this script has to let the user in to the site. This logic is the job of a Controller
- Likewise, when a user fills out the Register form and clicks submit, a script has to check to make sure they entered a valid username/password, and then if everything is ok, the script has to somehow create a new row in the database that stores that username/password. Then the user should be redirected to the Home page. This business logic is the job of a Controller.
- The Home page needs to check to make sure the user is logged in. It then needs to retrieve the list of friends of the logged-in user, the list of people who are not friends of the logged-in user, and then display that data to the user. The decision of what data to retrieve from the Model, and the job of then forwarding that data to the View which displays the interface, is the job of a Controller.
- The Friend’s Profile Page has the same type of Controller as the Home page. Data must be retrieved from the Model, and then that data must be properly inserted into the View for this page. So a Controller must be present to take care of this.
The Controller scripts that I have created for this application to handle these tasks are:
- authenticate.php – handles all tasks related to Login and Register functionality
- index.php – handles all tasks related to viewing the Home page
- profile.php – handles all tasks related to viewing a Friend’s Profile
- friendship.php – handles all tasks related to adding/removing friends
The Models
As should be clear by now, Models are necessary to handle the parts of this site where direct access to the database is needed:
- compare any username/password combo to those already stored in the database (necessary for the Login and Register pages)
- create a new user in the database (necessary for the Register page)
- create/delete friend associations in the database (necessary for the Home and Friend’s Profile pages)
- get a list of a user’s friends (necessary for the Home and Friend’s Profile pages)
- get a list of people who are not a user’s friends (necessary for the Home and Friend’s Profile pages)
The Model scripts that do these tasks are:
- models/User.class.php – handles any tasks related to creating, reading, updating, or deleting users
- models/Authentication.class.php – handles any tasks related to logging in or registering a user
- models/Friendship.class.php – handles any tasks related to friendships between two users
- models/Santize.class.php – handles any tasks related to data sanitization
To be consistent and complete, I have added the standard CRUD functions to each Model script, as well as the functions which handle each of the database-related tasks listed above.
It’s object-oriented
You can see that I have created seperate class files for each Model. I am combining MVC architecture concepts with object-oriented programming techniques. I have created classes for each type of “object” or “entity” that I think may conceptually need specific actions taken on it.
Object oriented programming is a seperate concept from MVC architecture. But I have used this example to exhibit both.
It uses a home-brewed framework
You can see that I have organized my code in a specific way. All Model files are contained in the models/ folder. All View files are contained in the views/ folder, and all Controller files are contained in the root folder. Javascript files would go in the scripts/ folder. Style sheets are in the styles/ folder, and database connection info is in the dbinfo/ folder.
One of the core features of a so-called “framework” is a clear organization of the files involved in a project. So you could call this organization that I have come up with a sort-of home-brewed framework. It is very simple, and crude, but it is effective at helping organize our MVC object-oriented application.
The popular frameworks that PHP developers use, such as Zend, CakePHP, Symfony, and CodeIgnigter, do much more sophisitcated things than just seperate your code into folders. So I doubt my framework will become the next big thing. But it is useful for our purposes nonetheless.
What the user sees
It’s important to note that the users will be completely oblivious to our use of an object-oriented MVC architecture. This is a good thing: you don’t want users to have to worry about how a site was developed.
When a user goes to the Login or Register pages, they will see the address authenticate.php in the browser address bar. This is the Controller script that we know handles all tasks related to logging in and registering. This controller figures out whether the user wants to see the Login Page or the Register Page, and loads up the appropriate View for either page.
When a user goes to the Home Page, they see the address, index.php. This, as we know, is the Controller file for the tasks related to the Home page. This Controller calls functions in the Model that get the data related to the Home page, and then this Controller loads up the View file for the Home page, which displays this data nicely.
Similarly, when a user goes to a Friend’s Profile page, they see the address, profile.php in the browser’s address bar. This is the Controller file for all tasks related to viewing the Friend’s Profile page. This script gets all the data by calling functions in the Model, and then includes the appropriate View file to display that data.
Loading ...