WCF multiple data contracts or multiple service contracts representing multiple data model classes?

Question

In my WPF application data model I have multiple classes representing data for interaction with backend DB through WCF self hosted service.

Should I have multiple Data Contracts or multiple Service Contacts or Endpoints in my WCF Sevice for representing these multiple WPF data model classes? What is correct (or maybe the only) way to architect WCF in this case?

Answer 1

In WCF terms a data contract is a class used in a service contract operation. It's called a data contract because it is usually annotated with the DataContractAttribute in order to be recognized and serialized successfully (although starting from .NET 3.5 SP1 DataContractSerializer works with POCO objects and this attribute is no longer required). So you could have a single service contract with multiple operations dealing with multiple data contracts all exposed in a single endpoint.

Answer 2

There is a design recommendation called Interface Segragation Principle which basically states what the iDesign WCF Coding Standards also say: don't make your interfaces (= your service contracts) too big and too unwieldy.

Consider this: you have a huge service contract with hundreds of methods, and some third party would like to implement a subset of functionality, maybe only two or three of those service methods. If you have a single huge service contract, they would have to implement their 3-4 service methods of interest, and all the others, they would have to stub a dummy - e.g. something like throw new NotImplementedException(); or something. This is not a good idea, in general.

So the basic principle should be: try to group your service contracts in such a way that if ever someone else needs to implement a subset, they most likely will find a single service contract that has all the methods they need, and nothing else. Try to group your service contracts by topics, e.g. if you have 6 methods to search addresses, put those in a separate service contract. If you have 7 other methods to insert new addresses, update and delete existing ones - that should probably be a separate service contract (since you could well imagine someone wanting to only search for addresses - not modify anything).

So I guess there's no real hard rule what is good or not - try to group your service into "logically connected" groups of methods. That's not an easy thing to do, for sure! But it's worth the effort to think about how others might be using your services.

Also, if you have a few smaller service contracts, it's also a lot easier if you ever need to change anything. If you need to introduce a breaking change into a service contract, only those (hopefully few) users of that particular service contract with a few methods will be affected. If you always have to change your huge 200 method service contract, you'll always affect everyone - that might not be a good thing!