Saturday, April 08, 2006


MVC - beautiful OO

It took learning C# for me to really get OO. I suppose that learning Java would do it as well, but Visual Studio Intellisense plus the strong typing of C# really put it in perspective. I'd probably read a hundered times that objects model the real world but I really saw it when I could see how a well designed object model worked. The first one I really saw was fairly simple - the Microsoft Virtual Server COM interface (as wrapped and marshalled by Visual Studio .NET 2003).

You start by getting an object representing the whole COM interface. This object has methods that return other objects, such as Virtual Server hosts. These host objects return machine objects, and so on. This model really didn't meaningfully demonstrate much, except maybe indirectly. For instance, encapsulation - each object contained enough data to do what it needed to do without needing tons of parameters passed to some arcane function. The namespaces were all clean and each object came with the methods I needed to get work done.

More reading and experimenting led me to the Design Patterns book, and time and community momentum has led me to Rails. It's not the first time I've seen Model-View-Controller. The afforementioned app I was working on was messy, and we had tight coupling between the UI and the business logic. My first peek at frameworks led to a lot of MVC and finally to J2EE. Interesting, but impractical since C# was the shortest distance between a web page and MSVS.

Time has changed a lot of things. VMware is the obvious winner in virtualization. Our organization has started to look at automating VMware server and I have been working off and on with Rails. Rails has a lot of great stuff going for it right now - Instantrails for Windows offers an almost perfect environment to get started. Several free (and free) Ruby and even Rails IDEs are out there (FreeRIDE, RDT, and RadRails for instance). A brand new release of Rails improved the maturity of the code even more.

But still I didn't get MVC. My understanding until yesterday was that the model handled populating and storing business objects in the datastore, the view created the HTML or other UI and the controller responded to all user input. I now think I had an overly narrow definition of the model. One of the things that got me thinking about it was looking at Typo, the CMS included with Instantrails. After poking at the app a bit, I started peeking around in their files to see how things were setup.

I started with the post class in the model. As expected, it's an ActiveRecord. That's the Rails object/relational mapper which handles storing and retrieving data from the database. The surprise was a method on the post class - ping. It's the method for pinging blog trackers like Technorati about new posts. So, my new definition of a model is the persistence and business object layer. It makes sense that a class that models a blog post would have a ping method. Pinging is universal to blog posts, regardless of the view or the controller. It's a beautiful thing. I can take my model from one application and move it directly to another because the model has no dependence (or coupling in OO parlance) to the view or the controller. Right away this helped clarify most of my "what goes where" questions.

If you're at all interested in Rails or MVC in general, take a look at the Typo code. It's clean and simple and not a bad way to learn about the possibilities.

This page is powered by Blogger. Isn't yours?