The Cake Is Not A Lie

I know it’s been a while since the last post, and I kind of left things hanging with the “end to end application strategy”, that rolled something like:

• Sql Server
• Data Layer — EFv4, with T4 templates for DTOs, and AutoMapper
• Service Layer (WCF REST)
• Web UI (jquery)

Well, the stuff I was doing with the data layer, with a few utility classes, and the T4 templates ended up being much more useful than I thought. Useful enough that it warrants more than just a couple of blog posts with some file attachments. Also, the more I worked with WCF REST, the more I hated it. Crappy date format when you serialize to json. No control over serialization. No cycles in your object graphs. No anonymous types. An ungodly amount of configuration. Ridiculous error handling (none of it global that “just works”). So, I started to shop around, and while some people are taking to creating REST services using MVC, I haven’t drank the MVC kool-aid yet, and that’s not really what it was designed for anyway, so I wasn’t overly keen on that route. However, a plain IHttpHandler….now we’re talking. You get whatever advantages you need from the ASP.NET runtime, but all you have to do is implement ProcessRequest(), which gives you an HttpContext, which is all you really need. You have full access to the request, and you create a response. There are excellent tools like Json.NET to help you with the json serialization. You just set the content-type of the response, and away you go.

Once I started making some REST services with plain old IHttpHandlers, the patterns started to emerge. How to process the query string. Well, I’d really rather have a nice route instead of some path to an ashx file. How do I differentiate between uri template params and query params? How should I generically return errors for bad input? What’s the best way to determine which service method to call in the IHttpHandler class? Like any man who was thinking, I tried to follow the DRY (don’t repeat yourself) principle, and centralize the logic for many of these tasks.

So, as our code and our approaches to problems always do, my “end to end” strategy was evolving into something much, much more. I ended up with 2 incredibly useful libraries: One for getting the Data Access Layer up and running (utility classes and T4 templates), and the other for creating RESTful services based on simple IHttpHandlers (with it’s own basic routing and processing engine). These libraries have been released on CodePlex. They are:


I have spent a very good amount of time polishing these libraries and running them through their paces, to make them production ready. I can happily say they are in use in some large, enterprise-scale applications right now. Yes, there are bound to be a few bugs here and there, but these are ready for production use, right now. I’ve also spent a very liberal amount of time creating overview pages that explain the gist of the libraries and how they work, and working examples. The examples and documentation can be found at http://restcake.net.

These are very small, unobtrusive libraries. Nothing enormous and overreaching. Read the RestCake overview page and the Loef overview page to get a feeling for these libraries and what they offer. You’ll see what I mean. If you have any issues or suggestions, please use the CodePlex pages to report them, and I’ll try to get on them right away. For now, I’m going to continue to improve the documentation and working examples, and iron out any bugs as they surface. As my good friend Jerry would say, “I’m just one man”.

Enjoy these new libraries! The cake is not a lie!