You may be wondering what happened to part 6. Well, it’s still being worked on and should be available early next week.
I wasn’t sure if there would be a part 7 and if so what it would be about – but I was heavily considering writing about an ActiveRecord implementation. Turns out that Kent Sharkey, beat me to it with his overview of Subsonic on DotNetSlackers.
I want to spend just a couple paragraphs trying to tie in Kent’s article with the Foundations series.
In Part 3 we talked about persistence and manually wrote our data access layer and mapping code. As I said at the time, doing that manually is fine for simple cases with few domain objects and straightforward mapping, but can quickly get out of hand. To solve the problem and keep us efficient, we can leverage existing O/R mappers to do all the mundane work. Some O/R mappers, like NHibernate which we’ll look at in Part 6, are unbelievably flexible and can be used to address very large systems (as systems grow in size, it’s common for their impedance mismatch to grow as well, which makes a flexible tool all the more important). Of course, NHibernate isn’t the simplest thing to configure and it has a relatively steep learning curve.
An alternative approach is to use the ActiveRecord (AR) design pattern. AR is still considered an O/R mapper, but it’s specifically targeted at more straightforward applications (which likely represent 95% of the work we’re all doing). AR is one of the two components that has made Ruby on Rails so popular and productive (the other is their first class MCV pattern implementation). There are two popular .NET implementations that I’m aware of: Subsonic and Castle ActiveRecord. Both the Castle and Subsonic line of products are open source, and come with a full range of products (MVC, ActiveRecord, Scaffolding, utility functions, etc) that integrate nicely with each other. Interestingly, Castle is implemented on top of NHibernate – which gives you a hit about just how flexible NHibernate really is.
With Castle ActiveRecord, you take your domain object and decorate it with attributes. You add the ActiveRecordAttribute to your class, and the PropertyAttribute to your properties. So, if you have a Car class with a Name property which are properly set up, Castle will automatically map to a table named Car and a column named Name.
It turns out that ActiveRecord implementations can be setup within minutes and handle 99% of all your data access needs. They can make you unbelievably productive by providing functionality and performance above that of DataSets, while maintaining your rich domain layer and allow you to easily write unit tests.
It’s still worthwhile to learn a more complex framework like NHibernate for a couple reasons. First, once you’re used to it, it too can be set up quickly and efficiently (avoiding upfront learning is a losing strategy). Secondly, NHibernate is a lot closer to important fundamental concepts. With AR implementations, a lot of the details are taken care of for you – which is great in most cases, but doesn’t teach you nearly as much. If you spend some time with NHibernate, you’ll learn about first and second level caching, identity map, concurrency and locking and various other concepts relating to persistence.
Happy holidays to all our CB readers and your families.