Catching up with the Castle Project

Catching up with the Castle Project

The Castle Project is an open source project that runs on .NET, providing an MVC (Model-View-Controller) framework similar to the popular Ruby on Rails. The Castle Project has been in development since 2003 and released Version 1.0 RC2, in November of 2006.  As the project nears its V1.0 RC3 we caught up with Hamilton Verissimo, the founder of the project, to talk about what the Castle Project is and where it's headed.

The Castle Project should be of interest to any .NET developer interested in new ways to create web applications on the platform or are particularly curious about implementing MVC-based applications. It is an attempt to provide tools and frameworks that make development on .NET world more enjoyable, fun and productive. It provides the means to create applications with more isolation amongst layers, promoting a good design.

We had to ask, what exactly the Castle Project is:

MicroKernel/Windsor - which are Inversion of Control containers. In fact, Windsor just aggregates the MicroKernel and provides external configuration and proxy support. The core idea of Inversion of Control containers (IoC for short) is to promote a loosely coupled design by removing the need to have your code creating and configuring services it depends upon.

Castle ActiveRecord - an ORM built on top of NHibernate . It removes the need to create XML mappings and abstracts some complexity out of NHibernate's infrastructure. Although the standard use relies on using base classes, this is not required, you can use ActiveRecord with different patterns like Repository.

Castle MonoRail - a web framework built on top of ASP.NET (do not confuse ASP.NET with WebForms). It puts controllers as the main player in a web application, deciding the flow, delegating to other layers and choosing views to render, hence it only cares about application flow logic. The views on the other hand, are only concerned with presentation logic. This greatly differs from the standard WebForms paradigm. It's the standard choice for people that came from web framework on other platforms as it allows you to have full control over the HTML generated, which is not true for WebForms and its controls.

There are non top-level projects but equally important like DynamicProxy (it's allows proxying interface and classes and it's used by several open source projects like NHibernate and Rhino.Mocks). NVelocity is also our fork of the defunct NVelocity on Sourceforge. We fixed several bugs, added some interesting features and optimized it.

Castle MonoRail offers different view engines to produce what is ultimately rendered to the browser. NVelocity and Brail comes with the Castle package, albeit there are other implementations of view engines from the community namely AspView and one based on the StringTemplate project.

The difference comes down to the fact that with these view engines we don't have a complex page lifecycle like WebForms. We don't try to reinvent the web paradigm to a stateful one which it clearly isn't. By sticking with the web as it is, we gain simplicity. By leaving Models and Controllers handle the data/state and flow/application logic, we leave to the views the role of simply displaying content, and for that we don't need anything more complex than ifs and foreachs. Content can be reused, though, by splitting views into different files or creating ViewComponents which can be seen as a view with some associated logic.

On the changes since RC2 was released:

ActiveRecord and Windsor had some improvements and bug fixes. MonoRail was improved greatly with the addition of cache support and JS generation. Cache can be configured on the controller level, and ultimately uses the ASP.NET caching infrastructure. JS generation is a way to generate a JavaScript code that changes the page. Usually it's used through AJAX, so imagine you have a page displaying some content and the user clicks a button that change the state of several things. The action can use JS Generation to render JavaScript updating the elements on the page.

This project has some obvious similarities to Ruby on Rails, when asked if Castle Project started because of the popularity of Ruby on Rails:

Castle started as home for the Inversion of Control container I had in my mind for like an year, between 2003 and 2004. Castle ActiveRecord and MonoRail came after my contact with Rails which was very young at the time (2004). I decided to build a product using it and had nothing but headaches with all non-standard requirements. .NET on the other hand, had it's great and documented library, with decent projects popping up everywhere. Although I loved Rails, it's just not the framework and platform I'd use for the kind of projects I'm usually involved with.

While MonoRail started as port of Ruby on Rails ActionPack, it diverged with all the contributions and ideas from users came with. Today it has its own identity, and while the foundation is similar we support things that RoR doesn't and vice-versa.

When asked about the future of the Castle Project and where Hamilton sees it headed:

Covering all the aspects of enterprise projects is the ultimate goal. And we balance that with offering products that are predictable, pleasant to work with and that give you a productivity boost. It's different that offering something complex and then an editor or code generation tool, which otherwise you wouldn't be able to work with. That's why our work differs so much from Microsoft's approach.

The Castle Project is an open source project and welcomes developers to get involved. Getting involved includes submitting patches that fix bugs, or add new features, add test cases or documentation. The first step to get involved is subscribing to the development list and start to participate on the discussions.

More information can be found at the Castle Project web site or at the wiki. Hamilton also maintains a very informative blog.