Request/Response Service Layer: Conclusions
Posted by Davy Brion on November 16th, 2009
Note: This post is part of a series. Be sure to read the introduction here.
Now that you’ve learned everything there is to know about the Request/Response Service Layer (RRSL), i’d like to repeat the benefits of the RRSL that i stated in a previous post:
- Since we only have one service contract with one service operation, we don’t need to spend time thinking about how to design and implement our service contracts and our operations. After all, every operation that the service layer must support is a specific request type that can be added, together with its requesthandler.
- We can keep our operations as fine-grained as we want (which increases reusability and overall flexibility), without having to pay the cost for chatty network communication by batching multiple requests per roundtrip as much as possible in a transparent manner.
- The actual implementation of our service is very minimal. It’s just a small class which resolves the appropriate requesthandler through the IOC container, based on the type of the incoming request. It then delegates to the requesthandler by passing the request to it, and it returns the response to the client. We can simply add ‘operations’ by adding request types and requesthandlers to our assemblies… everything gets registered automatically when the application starts up
- We avoid repetitive code for cross cutting concerns by putting it in a base requesthandler class that the other ones inherit from. That kind of code now only occurs once, and we can plug in custom code at any point of the execution by simply using the Template Method pattern.
- The implementation of our requesthandlers doesn’t contain any code that doesn’t have to be there. Each requesthandler simply implements the Handle method to handle the incoming request, and can do as it pleases to fulfill the request. All dependencies are injected automatically by the IOC container. It’s usually nothing more than using the dependencies to execute the necessary business logic and then returning a response-derived object.
- Since we only have one service, we only need one client proxy which never needs to be updated (technically, we have 2: one which is entirely asynch and mostly used in Silverlight clients, and one which is strictly synchronous and is mostly used by ASP.NET applications and Windows Services or command line tools.
- This single client proxy implementation can make sure that underlying WCF resources are utilized as efficiently as possible and cleaned up properly throughout the client application(s).
- The client proxy is easy to stub during unit tests which increases the testability of our client side code.
- Very little configuration. We only have to configure one client-side endpoint, and one server-side endpoint. That’s it.
- All of this is very easy to put in some kind of reusable library. Our applications simply reference the library, inherit from the base requesthandler types, make sure everything is registered properly upon application startup, add a couple of lines of XML and we can start the development of our service layer without any friction.
One of the goals of this series was to convince people that those benefits are indeed real. I really wanted to prove each and every one of those listed benefits and i hope that i succeeded at that. I also hope you realized how cleanly we can write our client code, as well as our actual service layer logic. I definitely recommend that you consider this entire approach for your future applications. While i won’t claim that it is the best solution for every project, it’s definitely one that can give you quite a few tremendous benefits.
Since i really don’t have much more to say about this entire topic, i’m just going to leave it at that 
November 16th, 2009 at 3:01 pm
First and foremost, thanks for the series, this is excellent documentation
I have adapted calling the dispatcher a bit so that you can have syntax like this:
dispatcher
.Add(s => s.Document = document, t => t.UserID = userID)
.Add(s => s.DossierId = dossierID);
I’ve blogged about it here
November 16th, 2009 at 3:14 pm
@Tom
very nice! i wish i had thought of that :p
definitely adding that to our implementation as well
November 16th, 2009 at 4:24 pm
Great series of posts, thank you!
Any chance you could post the source code as a downloadable package?
November 16th, 2009 at 4:31 pm
@Josh
i might… if there is enough interest then it’s probably better to create an open source project out of it, but then i would like some help from others since i don’t really want to take care of it on my own
November 16th, 2009 at 5:40 pm
I Have been working on the old version of the request response service layer that you posted with the intent of providing it as an open source project. I could put this up on codeplex and give you commit access?
November 16th, 2009 at 5:44 pm
@Aaron
i couldn’t wait so i’m already preparing a new open source project for this… just waiting for final permission from my employer before i’ll post the details
November 16th, 2009 at 8:10 pm
@Davy, we are using the RRSL in one of our projects already. I took the code from a while ago and adjusted it to work with Unity (have to work with Unity at my current client
).
I’d like to get involved when you decide to go opensource. Next to that, one of my commenters pointed out that using Action is makes for even more terse syntax
November 16th, 2009 at 10:25 pm
+1 for the open source idea, volunteering aswell. Although there’s probably other people better-versed in this specific area, I would be particularely interested in (smoke- or acid-) testing this (especially the concurrent) stuff though
November 16th, 2009 at 10:33 pm
@Kilfour
i already intended to invite you to join specifically for that purpose since i want to make heavy use of QuickNet for the tests
and you’re always welcome to contribute to the others parts as well obviously
November 16th, 2009 at 11:17 pm
Davy – thx for this great series. I know how difficult it is to keep up with great content on a personal blog, and I totally get the feedburner stats you’ve shared just a few days ago.
Keep it up.
I’ll be looking for the OSS version of this. I probably won’t have much time to invest in it, since I have prior OSS commitments (like, er, getting Monorail 2.0 out of the door)
November 17th, 2009 at 1:00 am
Alright, i have permission to release an open source library of the RRSL… i’ll probably post an official announcement in a couple of days once i’ve got everything set up
November 17th, 2009 at 5:02 am
It would be great if this became a google code project so other people could contribute and use it as a stand alone library
November 19th, 2009 at 8:17 am
Would it be feasible to have an implementation of this using .NET Compact Framework 3.5 on the client?
November 19th, 2009 at 11:16 am
@Josh
not sure… i’m releasing the open source library tonight so you could give it a try and let me know
November 19th, 2009 at 7:33 pm
I’m excited to hear that you’re open sourcing this solution! I built something like this in our current project but I couldn’t solve the problem of the KnownTypes and so we have the equivalent of your IRequestDispatcher, but it has one method per message. It’s ugly and I’ve not liked it since I wrote it.
Looking forward to seeing if I can integrate RRSL into our project and get rid of that ugliness. 
Thanks for the great library, and, as others have said, the great blog content. Keep it up!
November 19th, 2009 at 9:56 pm
Davy – i’ll try it on the Compact Framework once you release it and see how it fares.
November 21st, 2009 at 6:54 pm
Excellent post. Thanks for the effort in putting it together and sharing the knowledge.