Dear ASP.NET WebForms,
No longer will us web developers who happen to like C# and ASP.NET be a slave to your page lifecycles, control hierarchies and bloated viewstate. Never to fear, MonoRail is here! You may not want to read the following post as it may be damaging to your well known reputation among typical Microsoft web developers.
An Enlightening Experience
I've spent quite a few hours over the past few days playing with the amazing Castle Project (long overdue for me), mostly MonoRail and ActiveRecord. All I can say is WOW! As primarily a web developer who mostly uses ASP.NET, this is quite revolutionary for me. Like most ASP.NET developers, I've had to become very familiar with the managing the page lifecycle, postbacks and all of the stuff that goes along with it. Of course these things have their positives too (mostly for the "drag-n-drop your way to an unmaintainable enterprisey application" folks), but they definitely have their downsides, including hiding the stuff for which "web developers" really should have a good understanding.
Disclaimer: Again, I've only started to tap into what MonoRail and the Castle project as a whole can do for us as developers, so be sure to read, read, read all the good stuff on the Castle project's web site to really learn what these frameworks can do for you.
The MVP/WebForms Way
I've been heavily using the Model-View-Presenter pattern (I usually prefer the Passive View flavor) now for quite a while. It's greatly increased the testability of my ASP.NET/WebForm applications by abstracting most of the presentation logic into a separate testable layer of the application. So MVP has been great for testability, not necessarily for reusability for other UI implementations like WinForms as some claim (sounds great in theory, but doesn't really play out in the real world in my experiences). Unfortunately the page/view is the first thing that gets processed on each request. This is usually not a huge deal since most of the time the WebForm code-behind is usually just a series of property implementations and some code to wire up control events to the presenter. At least this is all it should be, but too often folks (sometimes including myself) are tempted to put logic into the code-behind that should be there, making it much harder to test. Hmm, the term "wire up" smells like infrastructure code. Let's see how a MVC framework could help us increase testability and reduce the amount of infrastructure code we have to write.
MVC To The Rescue
MonoRail is a true MVC framework for ASP.NET meaning the "controller" is the first thing that gets processed on each request, unlike WebForms as noted above. This is somewhat subtle if you're using MVP/WebForms since most of the presentation logic is still in the somewhat analogous "presenter" class. The beauty of MonoRail is that most of the infrastructure logic to wire the controller and view together are where they're supposed to be, in the framework. By favoring convention over configuration, you can develop your UI/Presentation layer very quickly with MonoRail. A couple great examples of this are the Getting Started article on the MonoRail site and this great screencast by hammett showing off some of the cool form validation stuff "baked in" to MonoRail. I'm not going to delve into all of the good stuff that MonoRail offers right now, but suffice it to say, what I've seen so far covers quite a bit of what most projects would need.
ActiveRecord.CreateSimplicity()
I've known about the Active Record pattern for quite a while and frankly it's taken me quite a while to warm up to it. Having methods like load and save on my domain objects has long turned me off from attempting its use in any of my projects. I've usually preferred to use something like the Repository pattern instead, which of course is still a great way to develop your data access layer. But after playing with Castle's ActiveRecord implementation, the simplicity in using it is quite refreshing. The fact that my domain objects "know" about how it maps to the database and load/save itself is something I'm still a little weary of, but I can't deny the huge benefits you can gain from using this pattern when its appropriate. As with most of the Castle projects I've played with so far, the syntax is very sweet and is definitely along the lines of a fluent interface. And the built-in extensible validation framework is just what the doctor ordered for one of my current projects. Imagine having your validation rules and error messages in a single place that can even be shown in the UI via MonoRail. This is reality as shown by the screencast mentioned above! You simply can't deny that kind of productivity benefit, and I'm all about increasing productivity without sacrificing maintainability.
Conclusion
So this should sum it up. In my first 2 hours playing with MonoRail and ActiveRecord, I was able to TDD my way into developing a significant portion of the domain model from one of my current projects, including validation, database schema generation, integration tests against a real database and some scaffolding in MonoRail for dynamic generation of basic CRUD pages for the domain model. Oh yeah, I didn't even get into scaffolding, but believe me, very cool indeed for rapid prototyping. And of course Windsor for IoC is a whole 'nother animal that is very powerful and kind of at the heart of the Castle project as a whole. So if you're like me, you're saying to yourself, "where do I sign up?". I hope to post a lot more on these topics including some sample code.
Resources
So here's a very short list of some the resources I've found so far: