In the past couple of .NET projects my company developed, since we met with no objections from our clients, we decided to use Castle (by way of its two sub-projects MonoRail and ActiveRecord) to see how well it would perform. Unsurprisingly, considering the care that went into the Castle code, they made .NET development altogether more bearable.

Castle is a collection of projects that includes database access layers (using NHibernate to power a ActiveRecord implementation), templating engines (of which NVelocity and Brail are but two examples), and a series of other services geared to rapid application development.

Although my experience with Castle is still small, I’m liking it. I always considered C# a good programming languages and many of its characteristics fit very nicely with the way I like to develop when using a ORM implementation. For example, the way Castle implements ActiveRecord is, at least in my opinion, a much better way to see what’s going one–a nice blend, indeed, of the Rails and Django approaches.

Obviously, since C# is not a dynamic languages, some things are much hard–or at least, much less flexible–than their Rails or Django counterparts. Castle is also lacking some accessories we’ve grown to love in Rails; to wit, the console and the database shell. Nonetheless, it also shines when debugging is necessary since Rails lacks a decent debugger (although Netbeans, if you are incline to use it, solves the problem nicely) and Django is also missing debugging tools.

Looking at the changes already present in C# 3.0, I can see Castle becoming even more pleasant. At the moment, it is already saving us a lot of work and I’m sure it will be a lot better in the near future.