Question

I have a web application that uses WCF to communicate with the back-end DB. I already have everything working but I was wondering if it would be better to split up my fairly large Service Contract into several Contracts.

As it stands the service contract is a single general file with all operations contained within it. I know I could break it up into smaller contracts that are assocaited with the Data Objects in my business logic i.e. A Person object has a PersonContract etc.,

I am just worried that the web application will have to reference several WCF Services instead of the one and suffer as a result of this. Will having several smaller contracts in anyway affect performance, either negatively or positively?

Thanks.

Answer 1

IMO the Single Responsibility Principle (SRP) and Interface Segregation principle (the “S” and “I” in SOLID) still applies to WCF Service Contracts.

The nature of refactoring would depend largely on what type of services you offer, e.g.

• Data Services => You would typically consolidate each web service around main business entities.
• Enterprise Business Services => Would typically consolidate groups of services around main business process themes (e.g. claims processing or order processing services)

But in summary, don’t be shy to refactor your services (especially if you can forsee new Operations being added in future), and also take any opportunity to refactor and reuse any common theme in the interfaces.

Edit : Apologies – w.r.t. Q about performance wasn’t answered. If you do find the overhead of multiple services problematic, you could compromise with one / few service(s), with many interfaces each, as in this SO post here. With a proxy, facade or service agent type pattern on the client, you could ‘hide’ the fact that your are in fact speaking to just the one / few services.