Agile Web Development with Rails – Chapter 2

Got.  To.  Learn.  Ruby.  On.  Rails.

Chapter 2

Chapter 1 was mainly a high-level introduction to Ruby and the Rails framework.  Chapter 2 starts off with some of the history behind the MVC pattern and how it was originally intended for “fat” client applications.  It’s interesting that when developers first started building web applications, they seemed to largely ignore patterns like MVC and just shoved everything together.  We developers soon wised up and came up with various frameworks like Struts and ASP.NET WebForms (which is a very poor implementation of MVC, IMHO). 

It then goes into the basics of how MVC works, which I won’t bother to repeat here, since most folks who read my blog are probably already familiar with it.  But they do a fine job of introducing how the MVC pattern works in Chapter 2 which is obviously essential in order to use an MVC framework like Rails.

And now we come to the touchy subject of the Active Record pattern.  I have a love/hate relationship with the Active Record pattern.  While I love its simplicity and ability to get something running very quickly, I’m also a huge proponent of Domain-Driven Design and rich domain models with persistent ignorant (PI) domain objects.  Castle’s ActiveRecord implementation is quite nice, however, especially since it allows you to use an ActiveRecordMediator instead of having to subclass your domain objects.  Many folks have talked about DDD within the context of the Active Record pattern.  Nelson shares his thoughts on Castle’s ActiveRecord from a DDD perspective on his blog.

At this point, Active Record in Rails is starting to grow on me, because I understand that the Rails framework is an “opinionated framework” and should only be used when it’s a good fit for your particular project.  Although, if you haven’t watched it yet, I would highly recommend you watch this keynote from DHH at RailsConf 2006.  David makes some very interesting points about how often you may think something is not CRUD, when in fact it really could be.  Then we get to see some more Ruby code, this time dealing with retrieving and saving objects using Active Record.  Again, the elegance of the code just blows me away. 

And finally is what they call Action Pack.  This pretty much encompasses the “V” & “C” parts of MVC.  View and Controller. 

The 3 main view template types are explained a little, rhtml, rjs and rxml.  Views using rhtml are basically the same as brail views (.brail) if you’re familiar with MonoRail.  They are just html files with ruby code sprinkled in to make the pages dynamic.  Rjs views are similar to brailjs views in MonoRail and are primarily used for javascript fragments and AJAX.  Rxml views sound very interesting.  Being that I’m not a fan of hand-writing XML files, I’m excited to see how I can use the ruby language to generate XML documents.

The Controller is where everything starts.  It’s responsible for things like routing, caching and session management.  It’s also where most of the interaction with your Model will take place. 

This chapter is wrapped up by telling you that now it’s time to start building some stuff.  Schweet!  🙂

Another Quick Tip: Asserting view renders in a MonoRail controller test