1. Organize your code with MVC
Jeremy Shafer
Department of MIS
Fox School of Business
Temple University

2. Course Overview We are here!!! To do: MySQL
2 Weeks
HTML & CSS
2 Weeks
PHP
3 Weeks
PDO
2 weeks
To do:
Organize your code with MVC (1 week)
Work with forms (1 week)
Use cookies and sessions (1 week)

3. Objectives Understand what the MVC pattern is.
Understand how the MVC pattern can be used to develop web applications (what files go where, and why)
Understand how functions can be used to perform database processing.

4. Basically… Basically, today is all about folders/directories.
Keep that in that in mind, and a lot of this material will make more sense.

5. Why do we need the MVC pattern?

6. The MVC pattern
The Controller: Acts like a traffic cop… receive user input and decide what to do.

7. The MVC pattern
The Model: talks to the database.

8. The MVC pattern
The View: specifies what the user can see.

9. The MVC pattern
SANITY CHECK! – In which of the above would you expect to see code that uses PDO syntax?

10. The MVC pattern
SANITY CHECK! – In which of the above would you expect to see a lot of HTML?

11. The MVC pattern
SANITY CHECK! – In which of the above would you expect to see a lot of if / else statements?

13. Up until now, you have been organizing your code like this.
Where do the files go?
Up until now, you have been organizing your code like this.

14. Now we are going to start using folders to manage our php files.
Where do the files go?
Now we are going to start using folders to manage our php files.

15. Collectively, this is all a web site.
Where do the files go?
Collectively, this is all a web site.

16. Where do the files go?
This is the home page (or landing page) for the site.
The single main.css file is used consistently throughout the site.

17. Inside the site, there are two applications.
Where do the files go?
Inside the site, there are two applications.

18. Where do the files go?
These folders contain model and view files that will be used on the entire site.

19. Where do the files go?
These folders contain additional supporting files used by both the catalog and manager applications.

20. This concept is commonly referred to as DRY (Don’t Repeat Yourself)
Why are we doing this?
There are three reasons:
Avoid repeated code.
This concept is commonly referred to as DRY (Don’t Repeat Yourself)

21. What’s in here????
Inside the product_catalog application we have index.php. In this context, index.php is the controller.

22. What’s in here????
We also have these views. Views are named here with the convention of entity-underscore-verb.

23. SANITY CHECK - If I were to see a view named product_add
SANITY CHECK - If I were to see a view named product_add.php, what sort of operation would that page be used for?
SANITY CHECK – Where would I expect to see the code that connects to the database and adds the product information? The same place (the view) or someplace else?

24. User Defined Functions and the Model

25. Getting data out of the database

26. Putting data in
Notice that this function doesn’t return a value. It has no return statement. It doesn’t really need one. But, what might be a reasonable use of a returned result in this operation?

27. What you will see in the controller.
Notice that this code is much lighter (more simple) than what the model is doing. Remember the controller is just directing traffic. It should defer “the hard stuff” like data manipulation to the Model files, and data presentation to the View files.

28. Setting expectations…
So that’s it, right? Every MVC application is structured exactly like this. Right?
Actually no. There are a lot of variations on the MVC pattern. For instance, some developers will put all the controller code in a folder named “controllers”, and others will have lively debates over where form validation should go. The important thing is to be consistent.
But now you have a whole new vocabulary for developing web applications. This vocabulary will help make every implementation of MVC more sensible.

29. We call the process of changing the file structure of a web site or a web application, without changing its appearance or behavior: refactoring.