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

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 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

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.