I am building a program which would have WCF support. I am using the MVC pattern. For each controller there is a WCF service class. e.g. I have CTRL.CTRLBooking, WCF.IWCFBooking and WCF.WCFBooking.
For each controller (total of 10) there is a WCF class and an endpoint.
Is this a good approach or should I keep all the methods I provide in one single class e.g. WCF.WCFService (considering their count would be no more than 25-30)?
The service contracts should not be very fine grated, this is avoid chatty operations but at the same time we should not try to group everything in one service contract, which may become hard to maintain, later on.
I think you should design WCF service contracts based on functionality e.g., all booking related operations can go in IWCFBooking contract and so forth. Then you can have each contract implemented in a seperate class.
It is not necessary to have one-to-one mapping between controllers and WCF service contracts. Service are supposed to be independent and reusable across many applications.
Have your cake and eat it too.
Group your methods into logical services, not necessarily by logical controllers.
The distinction being that a controller has a bias towards providing a set of services for an application. So a controller is a broader container holding services or sets of services.
You can use partial classes in order to have separate files for smaller groupings of methods within a service. At the extreme, you could even have one method per partial class file but I think that’s a bit too far. Look for natural groupings of methods and put those in a single file.
Try not to create monster service classes as individual methods tend to get buried within the volume of available methods. The MS tools for manually testing a WCF service can get really cluttered in this case. It also forces bigger service reference refreshes than you may like.