There’s a lot of buzz around the term Model-View-Controller (MVC) and frameworks. If you’re just starting to wrap your mind around how they work, this article is written for you.

If you’re considering using MVC, here’s something to think about: For a small project, such as a small-business website with very little server-side code and little to no database use, MVC is going to be more work than it’s worth. For something like this, consider using a simpler framework like WordPress or building plain HTML files.

But once you start a lot of custom interactions with the database and you begin writing your own functions, you’ll need to start considering how to manage your functions. MVC frameworks are perfect for this application. Besides splitting up your code, they often provide you with useful functions to do everyday tasks. My favorite MVC framework so far is Kohana for PHP. It has a clean folder structure to work with and is very lightweight. You don’t need to work through hundreds of lines of code to get started.

So now that you’ve decided to work with an MVC framework, here’s what you need to know.

1. The Model corresponds to the Database. While it is possible to write any kind of code in the controller, it is not intended for this use. Use the Model for any database query you will use more than once. Most Models are classes, meaning that they contain properties and functions. Neither the Controller nor the View will typically contain Classes.

2. The View corresponds to the User Interface. Here’s where you will put your HTML code, along with whatever client-side scripting. Although it is sometimes necessary to query the Database from the View, this is not how it is supposed to work. Try to refrain from doing this, because it will compromise the security of the MVC framework, potentially revealing things about your database that you wouldn’t want people to know about.

3. The Controller corresponds to nothing. Ok. It corresponds to both the Model and View. Since it’s not connected directly to the Database or the display, it’s somewhat hard to understand exactly what this does. In fact, the controller is where the methods of the classes are called. The class methods will query the database for you, so if you’ve named your methods nicely, calling them should return a variable or an array which you can pass through to the view. This would also be where you would process forms submitted through the view, handle navigation, etc. But you don’t have to wade through all the HTML tags and mixed-in PHP code.

Finally, you should end up with a minimal amount of PHP code in your view. If you’re working on a team, this means that your team members don’t need to be proficient in code to work with the views. And if you have a database expert, he doesn’t need to know PHP very much to set up the Model, just queries. And when you’re debugging, the MVC will give you an easy way to troubleshoot what is happening. You can usually tell whether it’s a view issue or a database query issue. And if it’s not one of those, then you know it will be in the controller.

So don’t fear. Dive in with both feet and give Model-View-Controller a try. Worst that could happen to you is you become addicted to it…