Avoiding web service god classes

Question

I have a complex RIA client that communicates with a WCF SOAP web service, the second a being the operative word. This has resulted in a dreaded god class containing 131 [OperationContract] methods so far and even more private methods.

Personally, I don't have a problem with this; I use search and the navigation features of Visual Studio to very easily find my way around the class. The other developers, however, are suffering due to this. They're the sorts that slowly scroll around looking for things (it's annoying to watch). I #regioned the class up into sections, but I'm the only one that seems to enjoy the benefits of this (they're of the seemingly-more-common #region-hating camp).

So, to be nice to the other programmers, and maybe enjoy some resultant benefits I'm unaware of, I want to refactor the monster. Here's the options I see available:

Option 1: Fragment the web service into separate services

What I don't like about this is it would break my client code. I would have to rewrite it to use the new proxy classes. Additionally, I would also have more WCF configuration to maintain (yuck!). Also, there might be custody battles for where shared private methods should belong.

Option 2: Use partial classes

This idea seems appealing to me. What I would do with this approach is have each source file (not too many of them) represent a functional division of the web service. For example:

MyService.svc.cs
MyService.AccountManagement.svc.cs
MyService.Preferences.svc.cs
MyService.MediaManagement.svc.cs

I worry a bit about this approach, because at a former company when I raised this as a possibility, one developer said it was a bad idea due to some nebulous "there are issues with partial classes" reason. I never got a better explanation than this, but I took his word for it.

Option 3: Something I haven't considered

I assume that it's not uncommon for a complex web service to create god classes such as these, so there must be some good practice approaches I'm unaware of. What techniques do y'all use to make your web service classes easier on the eyes?

Update

Thanks everyone for your input. I wish I could accept more than one answer.

I've read through your answers, discussed things with the development team, and for now, we're simply going to reorganize the service into partial classes. I'll leave comments on the other suggestions to explain why I'm not taking those approaches, at least for now. You all have given me some valuable things to think about for future development.

Answer 1

The partial class option sounds fine, because it basically gives you the benefits of option 1 while keeping compatibility on the interface exposed. There are no real issues with partial classes that I know of, and VS uses them on all designer files, which also wouldn't make sense if there were problems with that.

Answer 2

If you can refactor your service into separate partial class files that each encapsulates a certain amount of related functionality, you could as well refactor your service into separate classes that encapsulate this functionality. Your service would become a mere façade for these classes and their functionality.

Sometimes this won't be feasible and will complicate things even further, but you're the one to call cards here since you know your code base. In this case (after giving it a good brainstorming session with analyst developers), partial class files can still be a better option.

One thing is for sure. Your service must be refactored. (Edit: Code is not just for execution but also for maintenance. If it's hard to find your way around it's definitely not maintainable.)

And about that partial class issues. I wouldn't consider this a valuable comment until it's backed up by some real fact why they are an issue.

About refactoring
Think of your service as a web application user interface. Just like web applications use BLL classes an their encapsulated functionality related to single problem/aspect of the whole solution, so should be your web service. It should be an interface that also uses BLL classes and their atomic functionality. It's just not visual interface but rather API.

Answer 3

hey Jacob, not sure if this would help you directly, but you mentioned lots of Private Methods.

This suggests to me that your WebService is serving two roles, Logic, and Interface...but in fact, it should probably only serve one, that of Interface into your logic.

Would it be possible to move as much logic as you can into a nice namespaced Class Library, and just leave the bare minimum methods in the Service itself?

UPDATE:

In terms of why you should refactor, and/or how you should design your class library, some of the principles in the S.O.L.I.D principles could be useful to you. In particular:

• The Single Responsibility Principle
• The Interface Segregation Principle

Check the link above, and it'll have summaries on all the principles.

here's some SO discussions on it. If anyone has better links on these, please let me know, cheers

Answer 4

Re-factoring suggestions:

You don't have to have 131 operation contracts in one service contract. Break them up into one service contract per functional area. You will end up with multiple endpoints in your service, but does that really matter?

Put all service contracts and data contracts into a "contract only" assembly. Put the implementation classes into a different assembly (or several assemblies broken down by function). Put the web service facade into yet another assembly, which contains only a web.config file and lots of empty .svc files that point to the implementation classes.

Example of a re-factored .svc file, with no code-behind (since the "code-behind" is in a different assembly):

<%@ ServiceHost Service="Fully.Qualified.Name.Of.Implementation.Class" %>

An extra bonus of splitting the code in this way is that your client app doesn't have to muck about with svcutil.exe and service references. You can reference the contract assembly directly and use a ChannelFactory<IContract> to call the service.

Another bonus of this structure is that one service implementation class can now call another one in the same assembly in the same consistent manner as an external call, but without the overhead of going through WCF.

Answer 5

Your first option is certainly worth considering, but you are correct about the added deployment overhead. A service with 131 operations sounds to me like it has too many responsibilities, but whether you consider this to be a problem or not depends on your usage scenario. If the service exists only to service your RIA client, this may not be an issue, since it's just an implementation detail - basically, the only reason to use SOAP is because it's an interoperable transport mechanism.

On the other hand, if you need to expose this service for other clients, it's not very composable. If that is the case, I would suggest decomposing the service into more manageable subparts.

No matter what you decide regarding your service interface, you should seriously consider refactoring your service into something more manageable. Ideally, there ought to be a Domain Model that implements all the behavior of the service. Such a Domain Model would consist of many classes, each with their own separate responsibilities. The service would then just be a Facade for the Domain Model. If all the operations do is to delegate their implementation to the Domain Model, 131 operations isn't too unmanageable.

Regarding your suggestion of using partial classes, I don't see how that is going to help. If you arbitrarily slice your current service class into a number of partial classes, it's only going to become even more difficult to find what you are looking for.

If, on the other hand, you find some logical grouping to order your partial classes, your are already on the way towards a deeper model. In that case, instead of partial classes, why not encapsulate such groups into concepts that can be modeled in real, separate classes?

In any case, I agree with Robert: The service must be refactored.

Answer 6

About your options/comments:

Option 1: I understand your concern, but you need to draw the line somewhere. You shouldn't just go on and end up in the future with a 1000 operations service, this time not for your code but for the caller. Also, there might be reason for the high number of operations in your scenario, just make sure to avoid a chatty API as you really don't want multiple round trips going on for the same operation.

Option 2 + regions: as u are saying, u have separate pieces of the app. Those shouldn't belong to the same class, and naming a few patterns won't really sell it well. Check this series, as its a journey on many of these things http://blog.wekeroad.com/category/mvc-storefront (do it from chapter 1) - it helped me a lot. U can also check this e-book on solid - http://www.lostechies.com/content/pablo_ebook.aspx. There is a lot of reason to many of the things currently going on, but none of them can really be transmitted in a catchy phrase.

As others have said, your service code should be just a tiny layer that translates to a service appropriate format and your application logic. Consider learning unit tests, those will seem ridiculous when u have been working with code like that, since it pretty much prevents u from using it well. That will continually remind u/point u to where u have your code all tied up.