I’ve been proclaiming the greatness of OpenRasta to anyone unfortunate to start talking to me about web development recently. I thought it was about time that I recorded the reasons I love it so much somewhere everyone can see.
OpenRasta is by no means a finished product but it has principles at its core that I value greatly and give it massive potential.
Unless you’ve been hiding under a rock for the past few years you’ll know how important I and many others think testability. If you don’t know why it’s important I suggest you go and check out Scott Bellware’s blog. He has written a series of post recently about how accountability and constant verification are vital in the search for productivity.
OpenRasta has been built with tests from the ground up and this fact shines through throughout the code base. I’ve never seen a code base like it; it’s beautiful. The entire framework is a testament to SOLID design principles which means extending it is childs play. When you’ve been used to frameworks like ASP.NET MVC where you will end up coding yourself into a sealed or extremely hard to test corner; OpenRasta is like a typhoon of fresh air.
Building upon a testable framework makes your code easier to test. For example, how many magically bound properties do you think your handlers (the equivalent of controllers) have? Zero. Zilch. They don’t even have an interface, never mind a base class. I’ll let you digest that one for a moment. No base class, no monolithic controller context, no magically appearing model state.
So what happens when you want to look at the details of a request or any of the state that OpenRasta has created as part of your request? OpenRasta, to enable it’s testability, revolves around a dependency resolver. All the details of the request are registered to this dependency resolver so all you need to do is take the relevant interface (yes I did say interface, not class, welcome to a world where everything you wish had an interface does) as a dependency to your handler. It really is that simple.
From the testablity you get a great deal of extensibility. There are several ways to jump in at various points of the request in order to manipulate it. The main ones are pipeline contributors and operation interceptors which I’ve shown how to implement before. OpenRasta comes with a default set of contributors and interceptors but gives you the ability to remove or replace any of them. Sure you can get yourself in a real mess if you don’t know what you’re doing but I like my tools sharp, powerful and dangerous. Especially something as pivotal as the framework I’m building upon.
You can of course implement your own binders, URI resolvers, etc. if you so wish. You could alter OpenRasta to work just like ASP.NET MVC if you desired. Though I wouldn’t recommend it!
As part of extensibility you can’t overlook the fact that this is true open source. Wish there was an enhancement to the core of OpenRasta or an extra method on an interface? Discuss it on the mailing list, code it (with tests of course) and submit a patch.
What I want from to see from a web framework is a deep understanding of web standards and the HTTP protocol. You will not find many people who know more about RFCs and HTTP than Sebastien Lambla, it’s actually quite disturbing how much he knows about them.
OpenRasta revolves around resources not controllers, generating URIs from types and individual objects rather than strings or at best lambda expressions. This takes a little time to get used to but it’s more powerful and easier to test. Why is it easier to test? You probably saw this coming but URI resolution is of course done behind an interface. Ahhhhh. So much easier than mocking a controller context.
OpenRasta also ships with content type negotiation. Your handler operations (akin to controller actions) return straight resources or operation results with a response resource attached. How this resource is returned to the client is a entirely separate function. Want to get a response in JSON instead of XHTML? Add .AsJsonDataContract() to your resource registration and just ask for it with the relevant Accept header. OpenRasta will transcode your resource to JSON for you and return it to the client.
There’s a growing following for OpenRasta, it’s being presented by Kyle Baley at MIX10 and this has caused the lovers of OpenRasta to pull together. We’re intending to improve the documentation giving more example of it’s use and generally helping Seb knock the edges off what is a great framework.
The OpenRasta mailing list is very active with people providing very rapid responses to any questions. If you uncover a bug Seb will often have a fix committed the very same day, with regression tests of course.
In the near future I’m going to churn out a series of blog posts or perhaps screen casts showing how I leveraged vanilla OpenRasta to create a simple wiki. Hopefully, this will help more people get started with OpenRasta.
If there’s anything in particular you’d like me to cover leave a comment below.
This entry was posted on at Tuesday, February 09, 2010 and is filed under Architecture, ASP.NET MVC, Community, Open Rasta, Quality, REST, Unit testing. You can follow any responses to this entry through the RSS 2.0. You can