Professional CodeIgniter®

1.2. Why Bother with MVC?

Although at first glance the MVC approach seems like a lot of work, it really isn't. When developers of the hypothetical MVC blog application want to change something about the home page, they ask themselves about the nature of the change. Doing so allows them to zero in on the part of the application they need to work on.

• If they want to change the number of blog posts that get retrieved (or even the order in which they are displayed), they update the model.

• If they want to change the way the home page looks, they update the view.

• If they want to add a new page to their application, they first add a method to their controller and then build out any supporting views (to display content in the browser) and models (to gather data from a database).

The beauty of the entire system lies in the fact that none of those hypothetical actions on any given part of the MVC triumvirate affects the others. It's true that changing the model in some way (retrieving 15 blog posts instead of 10) will change the view, but the developers didn't have to dig through their view (or controller) to make that change, then later realize they had another SQL call embedded in other files that did the same thing. Theoretically, on large projects, you could have developers who focus only on views, controllers, or models, thus keeping clean lines of sight on deliverables and responsibilities. (Stop laughing. It is possible, you know!)

If you work as an in-house developer, you'll quickly ...