A good framework is easy to learn

Castle is, for a .NET framework, refreshingly light-weight and loosely coupled. It consists of three major components: Windsor/Microkernel dependency injection container, Monorail Web model-view-controller engine and ActiveRecord object-relational mapping library. All Castle modules are simple and focused on a single thing only: Windsor does object wiring and configuration, Monorail routes web requests and ActiveRecord maps objects to database rows. Even better, they can be used in isolation or as a combination. Being clearly focused and nicely encapsulated makes Castle components fairly easy to understand. We are not required to eat the whole elephant just to get the benefits of a simple inversion of control engine, or to use the MVC pattern. That makes the learning curve really short. Windsor and ActiveRecord are so easy to understand that people typically start using them effectively after just a few hours of experimenting. Working with a MVC engine can require quite a mind shift if you have only used ASP.NET web forms, but if you have ever played with anything that resembles a MVC, then you should feel right at home with Monorail as well.

A good framework helps but does not get in the way

Castle’s dependency injection container, Windsor, allows us to benefit from inversion of control, but keep writing code the way it makes sense for us. Like Spring, it can auto-wire objects of any type. To use Castle’s services, our objects do not have to be written in any specific manner or contain Castle-specific stuff. Advanced features, like declarative transactions, can be configured externally without code modifications or applied to the classes using .NET attributes, that still allow the same code to be executed and reused outside of Castle.

A good framework works in harmony with other popular tools

I also like very much the practice to integrate rather than reinvent, taken from Spring. Each Castle component is clearly focused on a single thing and does it really well, and integrates with other popular opensource libraries and tools to do the rest. Instead of enforcing its own logging framework upon users, Castle components allow us to choose between Log4NET and Nlog. Monorail comes with the Brail template engine developed by the Castle team, but we do not have to use it. We can get the full benefits of Monoral with pages designed using NVelocity or ASP.NET forms templates as well.

A good framework makes simple things easy to do, but allows us to do complex stuff as well

ActiveRecord allows us to quickly create database backed objects by using simple code attributes and avoiding most of configuration typically required by ORM libraries. Should you require more advanced features, like using stored procedures instead of SQL commands for persistence, Castle also supports full-blown ORM frameworks like NHibernate and Ibatis. In fact, ActiveRecord uses NHibernate under the hood and provides default mapping configuration for its objects so that you do not have to worry about it. This idea of making simple stuff really easy to do is applied throughout the framework, promoting the use of convention over configuration (a concept made popular by the Ruby on Rails framework). For example, URLs are automatically mapped to actions by looking for the controller method that is named like the “file” part of the URL and using the “folder” part of the URL to determine the controller class name. All GET or POST parameters from the URL are automatically mapped to the action method parameters. Before Monorail, I developed a custom MVC framework for .NET based on Spring MVC. After migrating to Castle, I threw most of the configuration away — it was redundant anyway. Again, Monorail allows you to use more complex mappings with explicit configuration.

Convention over configuration principle is applied especially effectively in Microkernel. Microkernel deals with dependency injection and connecting application services (called components in Castle’s jargon). The real value of such libraries is providing external wiring and configuration for services, but very often there is only one type of a particular service used in the application. Microkernel automatically resolves dependencies based on the component interface. If there is only one IPlayerDAO service in the application, you do not have to explicitly reference it in the setup of every dependent component — Castle knows what you wanted to use. In addition to significantly reducing the amount of boilerplate XML that we have to write and maintain, this also makes the system easier to change. If we add a new argument to the constructor of the actual IPlayerRegistration implementation, we do not have to remember to change all the XML files where that service is defined — Windsor will wire the appropriate services automatically.

Some links for the end

If you are interested in finding more about the Castle project, visit http://www.castleproject.org. If you live in UK, drop by Skills Matter on the 15th of May for a free workshop on Agile Web Development using the Castle project.

Image credits: Orlando Pinto.