Robust Software

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.

Testability

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.

Extensibility

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.

RESTful

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.

If you directly return a resource from your operation, it is assumed that the request went ok and so a response code of 200 OK is sent back to the client. If you want to report a missing resource you can return an OperationResult.NotFound which will return 404 Not Found rather than just displaying your 404 view with a response of 200 OK. Why does this matter? It makes your javascript cleaner as you can request the resource in JSON format and check the response code rather than having to send a flag or some other work around.

Community

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.

What next?

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.

I’ve been looking into rails recently, partly to learn rails itself, partly to try and gain inspiration for the direction to take both the framework we use at work and Jamaica. It’s triggered me to question a lot of things that I’m doing in .NET so I’m going to attempt to record my thoughts.

Having testing and persistence baked in

One thing that has struck me is that I’m watching railscasts from years ago and they are demonstrating solutions to problems ASP.NET MVC is struggling with now. It really does have testing baked in but often not through the use of abstractions, instead they have made integration tests easy to write. It appears the entire request can be processed in memory without having to fire up a server all the way through to rendering the view. This is something OpenRasta is capable of and one of the reasons I get so excited about it.

Another benefit rails has is that it comes with a “model” baked in. This is something that is sorely lacking from ASP.NET MVC. Whereas the .NET world (particularly the ALT.NET sphere) favours NHibernate for persistence, they instead use a simple but well implemented active record implementation. Why have they chosen this? Partially because it works so well with a dynamic language, everything is DRY as code can be generated from the database at runtime. It’s also damn quick, something that has always bugged me about NHibernate is the 10-20 seconds it takes to create the session factory before you can get started.

Because NHibernate is so powerful and configurable it can quite frankly be bloody confusing for most developers, I get asked to help with problems almost daily. With active record everything is kept simple, this object is a row in that table. There aren’t often complex mapping files, it just works. Rails’ active record implementation has a layer of syntactic sugar based around pattern matching on missing methods which looks nice and works well. However, in .NET we have LINQ which is statically typed, very powerful and can serve the same purpose.

Why do we chose NHibernate?

The reasons given for choosing NHibernate are persistence ignorance, reducing the impedance mismatch, amongst others. Why do we insist on ignoring the fact that our applications are running on top of a relational database? What ever happened to embracing the technologies we are using to get the best out of them?

NHibernate lets you persist your domain models directly. So what? Who’s domain models are that much beyond dumb data stores in reality? I’d bargain it’s a hell of a lot less than those that claim to be doing domain driven design. Also, why does your domain have to be persisted directly? Why couldn’t you provide an empty domain object with a few active record objects and have it process them and spit other active record objects out the other side? Something CQRS-ish. Then your domain would contain nothing but business logic.

What does this mean?

I’m looking away from NHibernate, no tool should be chosen without question, even the great NHibernate. I just don’t think it is serving my needs as well as it could so I’m going to look for alternatives. Subsonic is top of my list, followed by revisiting LINQ to SQL, hell I might even take a look at the Entity Framework.

While we’re at it, why do we chose relational databases without question? I’ve been working with Lucene.NET a lot recently, it’s really easy to use and you get full-text indexing for free if you were to use it as a data store. Only want to deal with aggregate roots? Store all the data of that aggregate root in a single document, it can easily emulate nested structures.

Random deviation onto REST

I’m also being influenced by how REST appeals to me. It seems like a simple yet powerful way of dealing with the web. If we consider everything we work with as a resource, a representation of an idea, why can’t that representation be stored as an active record? The transition of an idea between resources could actually be a record transferring between tables. The old representation could even hold a reference to what the idea became, allowing you to redirect to the current representation. Hell, wasn’t the web made for storing and linking documents before it got bastardised into the beautiful beast we have today? Perhaps a document database would be ideally suited!

Pain points of ASP.NET MVC

Talking of REST brings me back to another problem I have with ASP.NET MVC. The routing revolves around controllers and actions rather than the resources and HTTP methods. In order to generate URIs, you will at some point end up having to manipulate strings or create anonymous objects. How do rails and OpenRasta deal with this? By using resources and their types to determine the URIs. This is so much more powerful and dare I say easier to use and understand. I can see it empowering the use of generics within .NET and it cuts out a hell of a lot of crap around URI generation.

Ah, cutting out the crap. ASP.NET MVC is testable, until you want to test something that isn’t a just a controller action. Like a HTML helper, URI generation or store the IP address of the request. Most of these things are kind of testable, but you have to mock out a complex object graph like HttpContextBase or ControllerContext. “We got rid of HttpContext.Current and replaced it with something slightly less monolithic and slight less sealed, go us!”. Know how OpenRasta deals with this? It has dependency injection at it’s core and there’s an interface that lets you retrieve everything you need, either separately or together. There’s everything from IRequest to ICommunicationContext (the equivalent of ControllerContext) and everything in between. You need it, you can retrieve it and it’s bloody easy to test.

Wrapping up

There’s a lot of random ideas here, I can’t say which I’ll end up using. Perhaps none of them, perhaps an unforeseen combination. If nothing else writing this down has helped me distil a few of them into clearer thoughts.

Here’s to questioning everything you believe to be true.

I’ve been questioning my own practices recently, seeing if there were places that I could improve, both in quality and productivity. Part of this process involved an evaluation of my test-driven approach (TDD) to developing software.

I have gained and learnt so much by practicing TDD. I believe there is no better way to instil the SOLID principle within both yourself and your code than to practice TDD. Violate any of the principles and you feel the pain in your tests, they will either become monolithic and hard to write or continuously break.

Here lies the chicken and the egg situation: to write good, robust tests you have to understand SOLID; to understand SOLID you have to be testing your code. This creates quite a hurdle that many people don’t put forth the effort to overcome. This is a shame but I think an excellent way of splitting the wheat from the chaff. In order to become proficient at testing you either need to have a natural talent for writing good code or the persistence to break through to the required level of understanding. Both of these qualities are equally valuable, having both would be fantastic.

The quality of code produced by TDD has never been in doubt in my mind. What I am questioning is the return-on-investment (ROI) of each test I write. Sometimes I feel I am writing a test for the sake of writing a test, producing very little value in the process. The kind of scenario where this is most apparent is the sort of code where if you were to not have written it properly nothing would happen or it would blow up in your face. Code with real binary levels of success, often with a single path through it.

This is the elephant in the room of all TDD discussions. When am I testing too much? The standard response of “NEVER!” is a lie but you have to have practiced TDD for a decent while until you can judge when you’re going to be writing tests with little worth. I’ve identified a subset of tests that I’m probably wasting my time in writing which are clouding the overall message of my test suite. The problem is that I am responsible for mentoring several developers in how and when to craft tests. I have to lead by example and until the whole team reaches a higher level of understanding of TDD I have to test everything despite knowing some of the tests I write have little to no value.

How can I test everything without writing these low value tests? Currently I’m looking at integration acceptance tests that describe the behaviour of the system. These will verify that the several layers of the application interact as expected in given scenarios to produce the desired behaviour of the system. These will likely have meaty setups and meaty verifications but they will remove the need for multiple low ROI tests. They are likely to be more brittle than unit tests but so long as I verify outcomes rather than interactions they should be fairly robust. What I’d love to experiment with is getting the stakeholders to help me write these acceptance tests, but this will have to wait until I’ve settled on a style for writing them. There’s nothing that harms adoption of a practice more than the first interaction to be a bumbling mess as you are not sure of what you’re doing!

As a company, we are also looking to hire testers this year. This is another thing stopping me from cutting out the low ROI tests. If I do not test my code, it will not get tested through anything but a manual process. Once we have testers I may be able to just write the tests that drive the behaviour and design of my code, leaving the full suite of tests to be developed by the testers.

So what have I learnt over the past few years? Is test-driven development worth the effort? Most definitely. The quality of my code has come on leaps and bounds and each time you do a major refactor of a well tested code base is a revelation. I find I write less code to do more and writing less code is always a good thing.

It’s harder to be sure you spend less time fixing bugs if I’m honest but I’m confident it’s the case. If you’re just starting out with TDD or unit testing in any form, start tracking the hours spent developing versus bug fixing. It would be interesting to see some empirical values on the subject.

Here’s to future years of TDD. It’s going to be interesting to see where my practices go.

Sebastien Lambla, who created Open Rasta, mentioned that I could use an operation interceptor rather than using a pipeline contributor as in the first “A better ActionResult” post.

I must admit that I didn’t know about operation interceptors which is the main reason I didn’t use one in the first post. I took this as an opportunity to learn a bit more about Open Rasta and so looked into what operation interceptors are and how to create them.

Creating an operation interceptor is an unsurprisingly simple task. You can either implement the interface IOperationInterceptor or inherit from OperationInterceptor which implements IOperationInterceptor with virtual methods that have no effect on the operation.

The latter is the easiest thing to do so that’s what how we’re going to implement our interceptor.

The IOperationInterceptor has 3 methods: BeforeExecute, RewriteOperation and AfterExecute. We want to work with the result of the operation so we’ll override AfterExecute. The way the interceptor works once invoked is virtually identical to the pipeline contributor, bar a little refactoring, as you can see:

This is a direct replacement for the pipeline contributor. It uses the exact same commands and command handlers as the pipeline contributor so the only other difference is that we have to register the operation interceptor rather than the pipeline contributor:

That’s all there is to it. Really simple given we had the code for the pipeline contributor already.

The only difference between the pipeline contributor and the operation interceptor is that rather than dealing with a single operation result there could be multiple output members. From what I can gather there is only ever one output member which is the assumption I’ve embedded in the interceptor but I may be mistaken.

Reflecting on the two approaches, I don’t think there’s much to chose between the two. I prefer the original method of using a pipeline contributor. It is more visible via the debug output of the pipeline and it is easier to retrieve the operation result at that point. However, knowing that operation interceptors exist and how to use them is beneficial. Another weapon in my Open Rasta armoury.

I’ve been meaning to blog more about my experiences with Open Rasta but haven’t had a sufficiently focused topic to work with so far. However, whilst reading Jimmy Bogard’s post on a better ActionResult I thought doing similar would be equally possible with Open Rasta. Go off and read Jimmy’s post if you haven’t already because I’m going to assume you have.

First, some things to know about Open Rasta. It handles requests by passing them through a pipeline. Now this isn’t some mythical process that you have to spend hours working out as with MVC. It is instead made up of pipeline contributors which you register as part of your configuration. To help you debug Open Rasta prints out all the contributors in the order they’ll be executed for you during initialisation. Another difference in Open Rasta is what things are called, controllers are handlers, actions are operations, action results are operation results and models are resources. Their function is similar enough to require no further explanation in the context of this post.

Open Rasta gives you about 15 contributors to form the basis of request handling which you can replace or add to as you see fit. What we will do in order to emulate Jimmy’s code is create a new contributor and insert it into the pipeline. These are pretty simple to create and register, here’s all the code for our custom pipeline contributor:

The Initialize method is called during initialisation so that Open Rasta can determine where in the pipeline you want your contributor to be invoked. The KnownStages class contains a bunch of interface aliases for significant stages in the standard pipeline allowing you to latch onto them without tying you to an implementation.

KnownStages.IOperationExecution is the Open Rasta equivalent of invoking the controller action and KnownStages.IOperationResultInvocation is the the equivalent of executing the ActionResult produced by the action. We’re slipping in between these two steps so we can execute our command handlers when needed; allowing us to change the OperationResult before it is executed.

So what do we actually do when this pipeline contributor gets invoked?

First we check if the OperationResult attached to the ICommunicationContext is of the CommandOperationResult type. This is identical to checking whether the ActionResult is of the BetterActionResult type in Jimmy’s post. If it isn’t we exit our pipeline contributor, telling Open Rasta to carry on to the next stage in the pipeline.

If it is a CommandOperationResult we retrieve the type of the current OperationResult and use it to register the OperationResult with our dependency resolver for the lifetime of the current request. The reason we do this is to be able to take the OperationResult as a dependency of the command handler. I’m not sure if this is any better but it does avoid using reflection to execute the command handler.

As a side note, Open Rasta uses an IDependencyResolver interface which is used throughout the codebase. It ships with it’s own implementation; I know there’s an implementation for Ninject and I think there’s one for StructureMap knocking around somewhere. I’ve only used the internal implementation as it does everything I’ve needed so far.

We then work out the type of CommandOperationResultHandler we’ll need to handle this command and use it to retrieve an instance from the dependency resolver. Again, this is very similar to Jimmy’s code apart from the fact that we cast the result as an ICommandOperationResultHandler. This is the second of the things that lets us avoid reflection.

We execute the command handler, which will have taken the CommandOperationResult as a dependency due to us registering it earlier. It could also take the ICommunicationContext as a dependency as Open Rasta registers that for you, as it does for IRequest, IResponse and the other things that make up ICommunicationContext.

The result of executing the command handler is set as the OperationResult of the current ICommunicationContext, this encourages you to swap out the CommandOperationResult for one of the standard OperationResult objects which will then get handled as normal by the next stage in the pipeline, KnownStages.IOperationResultInvocation.

Here’s my equivalent of Jimmy’s DeleteRequestResult and DeleteRequestResultInvoker:

This is how you would issue the delete command from your handler:

Last thing we need to do is register our pipeline contributor and command handler so they will be used.

That’s all there is to it.

Personally I prefer how this works in Open Rasta but then I would say that. I like how the result is manipulated by adding a step to the pipeline rather than having to override behaviour as in MVC. It just seems tidier and more flexible. The other differences in implementation could be transferred and are probably a matter of personal preference.

Which do you think is better?

I’m getting a bad feeling about yet another high-brow architecture. CQRS is a complex solution to a complex problem.

*NEWSFLASH*

Your problem is not complex enough to warrant the overhead of a complex solution

For the 1% of people who can rightly say “but my problem is complex enough” ask yourselves this: is it really that complex? I mean really.

Be honest now. Are you jumping at the latest architecture all the cool kids are talking about? Do you have twenty message buses passing data around because your intranet application might need to scale to millions of users one day? If you do, you probably don’t need CQRS for technical reasons but because you’re an architecture addict.

If you’ve got this far you either really do need to use CQRS or you have serious problem. So ask yourself this, you’re probably an architect or senior developer. Can the rest of your team fully understand the directions you’ll be giving from your ivory tower? If half of them can’t you are choosing the wrong architecture. I don’t care if it fits your problem perfectly. If your team can’t handle it, it’s the wrong choice.

If you still think CQRS is the right solution then you are in a very select group. You have a complex domain, scaling is a big problem for you and you have a team capable of taking the burden of a complex solution. Are you hiring?

That or you’re completely deluded.

Or you are a SOA consultant that is selling CQRS as the silver bullet for all development problems.

And I hate you.

“What is BDD?” is a question that’s been doing the rounds lately within the altnetgroup and devbookclub. There’s a great deal of mysticism surrounding it as if it were some exclusive members club. I’m going to slay some of the myths and tell you what BDD really is.

Myth 1: BDD requires a framework or tool

You don’t need to use MSpec, RSpec, Cucumber, etc to practice BDD. Sure they can help but they are not a precursor to being a practitioner of BDD. You don’t even have to write your tests within a certain construct such as Given-When-Then.

Myth 2: BDD requires UAT

User Acceptance Testing is a great concept but is one of those practices that only the elite working with an exceptional client get to do in real life. If you have UAT as part of your process, all power to you, but that’s all it is, part of your process. It is not part of BDD. It is merely coincidental that BDD style tests are the best way to express your acceptance tests.

Myth 3: BDD has to be done top-down

It is easier to approach BDD in a top down manner. But much like its easier to put your underwear on first, that doesn’t work for everyone in every situation. Just ask Superman. The proponents of BDD often state things in a radical fashion due to a fear of BDD being thrown in the same pot as TDD. That doesn’t mean that every time they say “you must” they actually mean it.

So what is BDD?

At its core, BDD is TDD done with a specific mindset; testing the intent of the system rather than testing a particular piece of code. The difference is subtle but the effects are large. There’s an entire discipline dedicated to the power of semantics after all.

It is the difference between “when I add a new post to my blog, the new post shows up on my homepage” and “calling the create new post method on the blog controller saves a new post and the new post is passed to the homepage view when the home controller’s index action is called”. Both sentences describe the same code, the BDD style signals the intent and is decoupled from the implementation. The non-BDD style describes what the code is doing almost line for line. The decoupling of the tests from the implementation is where the largest benefit of BDD comes from. Your tests will be less brittle making refactoring easier, perhaps even fun, making your code more malleable.

The myths aren’t completely unfounded, using constructs such as Given-When-Then helps enforce the required mindset. Frameworks such as MSpec, RSpec, Cucumber or even a bespoke one help you write tests within that construct. Working from the top-down helps you work from the behaviour of the user interface down to the behaviour of the data access. UAT helps you drive the behaviour of the system from the requirements of the client.

That’s all these things do though, help you develop in the BDD style. You can still write your code in a non-BDD style using all these frameworks, tools and processes, just as you can develop in the BDD style using none of them.

BDD is a state of mind.