MVC-Cravings
As I started working on the data models for Bloxer, I realized how truly dependent I've become on the Model-View-Controller (MVC) meta design pattern. There's a ton out there on MVC but the basic gist is this: you separate your project files into three overarching categories (model, view, controller).

The model is, typically, a class-based representation of your database. Often, you will have a class for each table in your database (this is meant very generally as you will often have other types of models in real-world applications). The view is a file or collection of files used to present data and UIs to your site visitors (often a collection of HTML files with some code from your desired server-side language mixed in. The controller is a lot like a circuit board or traffic cop, directing the flow of the application based on visitor requests.

The use of MVC has risen dramatically (and that may well be quite the understatement) over the past few years...and with good reason. While not trying to debate the merits of MVC or one framework's implementation of it over another, I do want to say that, without question, my development life has been made easier by using MVC and, in terms of web application development, we should all be using it.

Some basic benefits of MVC include:
  • relief from much mental clutter (where did I code that function?)
  • code reuse (MVC project typically result in smaller files, each with a very specific task, making it easier to reuse)
  • application scalability (easier to expand or contract the breadth of your application)
  • an intrinsic understanding of your application (by using this meta pattern, I inherently know where all my files are located, what they *should* be doing, and, often, how they interact and inter-connect).
Below is a screen shot of the file system structure in a sample Rails application (it's the PhotoShare application from O'Reilly's excellent book: Rails Up and Running, 2nd ed).

I opted to take a screen shot of a Rails application's file system because Rails is a framework based on convention over configuration. By using a standard convention (i.e., all models are in app/models), the Rails framework can locate and perform many tasks auto-magically, thus saving you from typing a lot of commonly used code, freeing you to focus on more important tasks and problems in your application.

A Rails Implementation of MVC

The "app" folder is the key for our purposes. Note how Rails breaks up the models, views, and controllers into corresponding folders. In particular, checkout the structure of the view folder. Its subfolders, save for layouts, mirror the names of the models. To me, this file structure intuitively helps me stay organized and keeps me on track.

Now What?
So, what's next? Well, I'm going to take a two-pronged attack going forward. On the one hand, I will continue to design the Bloxer application (creating models, detailed functional requirements, etc.) and, on the other, I will begin to develop a (very) basic MVC framework (JaxerMVC) for running the blog. At some point soon, I will step away from Bloxer, pause the posts on it, and wrap up JaxerMVC. Then it'll be back to Bloxer.

This weekend, I will add my next two posts: (1) Bloxer Models and (2) JaxerMVC Planning and Design.

Comments