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