How to use the single responsibility principle in large wcf services?

Question

We're using about 7 services at the moment. There quite large.

Does anyone have any experience with the single responsibility principle and WCF services? Does this mean that you'll end up with lot's of small contracts? If so, how do you manage these in your application?

Answer 1

I think you are confusing single responsibility with interface segregation.

From the client/service interface perspective, you should keep your contracts lean and mean. See below for an example of that.

On the SRP side of things, that should be entirely internal to the service implementation and the client should not be aware of this. If you service code is too large, split it up into classes. Then have your service code, at least initially, act as a facade and forward all the calls to the relevant objects. Later on, you have the option of spliting your service into multiple services. But be aware, that SOA and object oriented design, although overlap, are separate and have different requirements.

Interface segregation example: We have a service here at work that we use to do various functions on some business objects. The original service had one interface. As it grew, we realized we had three family of methods: data object persistence, business updates, business analysis. We split up into three contracts. Our client/service implements all 3, so the only thing we had to do was split the contract into three and setup two additional endpoints in our WCF configuration. Very simple.

Hope this helps.

Answer 2

I would suggest you listen to this podcast on the hanselminutes :

SOLID Principles with Uncle Bob - Robert C. Martin

It would help understand things better. . .

Answer 3

You could apply facade pattern for the web service that interface with the client, and in your implementation code you can apply single responsibility to make it maintainable.