· PHP Architect· www.phparch.com
An Introduction to MVC Using PHP
(fancy words for anything that stores and retrieves databetween web requests). Models can implement any of the technologies that make PHP such a great language for web development: databases calls, file manipula-tion, session management, web services, and anythingelse that stores data for your application. A well designed model could be used for other appli-cations on your web server. When you start to see thepower of encapsulating your business logic with theseclasses, it becomes clear that making good models is avery useful convention, even if you are not using the full MVC architecture.For models that interact with a database table, a sin-gle table should ideally be associated with only onemodel class. This helps you to achieve the first goal welisted for benefits of the MVC: maintaining your data insome kind of persistent data store. By just adhering tothe MVC framework, you only have to review the mod-els in your system if the database table changed. Byadopting this strategy, you would only have a singleclass in the model to review.Examples of typical models in web applications mightbe the user, the browser, a shopping cart, catalogitems, orders, topics or articles. I find that for database-driven web applications, models tend to be associatedwith a single table, or with a small group of tightly cou-pled tables (perhaps a view?). The name for your model class is likely to be similar to the name for your database table, assuming you have a reasonable nam-ing convention in place.I also tend to write model classes for features on thesite. An example of this could be a multi-page form,which may have a “wizard” model associated with it.
Views are the portion of the MVC application that pres-ent output to the user. The most common output for PHP web applications would be HTML, but views arenot restricted to this. Your MVC application might out-put XML, WML, plain text, images, email or some other content. PHP has a variety of capabilities to use inviews, ranging from just being designed to send databack to the browser, to implementing template solu-tions, to XSLT. Views generally create instances of models, and usemethods of these models to get data to present to theuser. Views contain all of the PHP code required totransform the raw data from your models into the for-mat you want to present in your application. For exam-ple, in the April issue of php|architect, I published anarticle covering the use of PHP for graphing. This kindof graph generation code would belong to views in aMVC.
The controller is the heart of the MVC application. Thiscomponent is the object that should be aware of theuser’s HTTP request (alternatively, the controller mightbe aware of the command line arguments or last inputin a CLI). From this information, the controller shoulddetermine what view to display, or what other applica-tion-related action should take place.Controllers are generally the core component of anyMVC project you may adopt (primarily because modelsand views must be customized to your application bytheir very nature). Various projects have differentstrategies for determining how the views and modelsinteract. How these objects interact is referred to assystem coupling. If the nature of these relationships isdefined using a configuration file (often XML based),this is said to be “loose coupling”. This is the oppositeof hard coding application flow into your system.To summarize, figure 1b depicts figure 1 with theappropriate PHP technologies added to each compo-nents sphere of influence. Will there be any crossover of these technologies inreal world applications? Probably. In fact, one exampleof this is depicted in figure 1b. If your application con-tained a “User” model and you have a “remember me” feature, you might want the User Model to send acookie to the client’s browser. This is technically donevia HTTP, a task which we assigned to the controller. Ihave also had cases where a view might be displayinga particular instance of a model, and which one to dis-play is passed as a parameter of the URL. As a result, theview might access this information using the $_GETsuperglobal (again HTTP bleeding in from the con-troller to the view).
Where you should not see any crossover of thesetechnologies is between the views and the models. You