Ok, how about an example of something that is certainly NOT MVC...
A function called DisplayUserProfile which uses SQL calls to retrieve some info from the database, formats that data, cleans up the spacing, calls the template or templates, and finally outputs the user profile.
This really hurts your flexibility and prevents developers from writing powerful plugins because they must try to jump in the middle of your displaying the profile, and interfere with the HTML that would normally be output.
An MVC way to do it is:
- You have a function which *retrieves* the user profile from the database, and prepares the information. This function has no idea how the data will be formatted or displayed.
- You have a function which takes that information and formats it to be displayed. This function has no idea how the data is stored (MySQL, PostgreSQL, XML, RSS), or what device will display that data (iphone, web browser, XML feed, RSS feed).
- You have a function which displays the final template. This function has no idea how the data was stored, or how it was formatted.
This sounds overly complex, but by doing this, third party plugins can completely change how user profiles are retrieved, stored, formatted, and displayed, by extending all of those functions. Not just profile fields, but really ANY type of information or functionality you would want to marry to the user record.
This is why I'm so excited about
Style Properties. Look at the
Notices feature in vBulletin. Great idea, but limited by the design. We couldn't really extend what triggered it, how the data was formatted and displayed, and we couldn't add a SQL query or other data retrieval.