InfoQ

InfoQ

News

My Bookmarks

Login or Register to enable bookmarks for unlimited time.

The content has been bookmarked!

There was an error bookmarking this content! Please retry.

Catching up with the Castle Project

Posted by Robert Bazinet on Sep 13, 2007

Sections
Development
Topics
.NET ,
Web Frameworks
Tags
Frameworks ,
nHibernate ,
Castle ,
MVC

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.

With regards to the technology provided by the project for rendering views:

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.

No comments

Watch Thread Reply

Educational Content

Cool Code

Kevlin Henney examines code samples to see what can be learned from them starting from the premise that one won’t write great code unless he knows how to read it.

Collaboration: At the Extremities of Extreme

Jason Ayers share the observations he made watching a team of developers collaborating in real time on the same code base, pushing XP, pair programming and continuous integration to their extremes.

Yesod Web Framework

Michael Snoyman presents Yesod, a web framework written in Haskell and containing a web server, templating, ORM, libraries (templating, gravatar, etc.).

Transactions without Transactions

Richard Kreuter and Kyle Banker on how to avoid classical RDBMS transactional systems by using compensation mechanisms, transactional messaging or transactional procedures.

Attila Szegedi on JVM and GC Performance Tuning at Twitter

Attila Szegedi talks about performance tuning Java and Scala programs at Twitter: how to approach GC problems, the importance of asynchronous I/O, when to use MySQL/Cassandra/Redis, and much more.

10 tips on how to prevent business value risk

One category of risk that project teams need to ensure they address is business value failure – delivering a product that fails to provide value for the business investor.

Interview: Software Systems Architecture: Working With Stakeholders Using Viewpoints and Perspectives

InfoQ spoke to the authors of Software Systems Architecture on a couple of new topics, the System Context viewpoint and Agile, which have been added to the second edition.

Beauty Is in the Eye of the Beholder

Alex Papadimoulis discusses ugly code, where it comes from, how to avoid it, and how to get rid of it.