Are Enterprise Level DataContracts a Good Practice?

Question

Is it a good practice to define DataContracts in an enterprise level assembly and then reference them in WCF service projects as opposed to defining them at the individual WCF service solution level? All of the WCF examples that I have seen have avoided that topic and have only defined DataContracts in the service solution. Some programmers I converse with want to see DataContracts as a different flavor of an enterprise level canonical data model instead of a service local contract. I have yet to find any arguments for or against that point of view.

It may be difficult to choose a correct answer to this question, but I will try. I will at the very least give upvotes to anything that I feel adds to my understanding of the topic.

Answer 1

I really like the idea of putting DataContracts (and Service Contracts) into assemblies and then sharing them with the services and clients, etc, but I don't see any good reason to put them all into one monolithic assembly.

It makes more sense to make to put them into assemblies based on how they're used. If there are groups of them that are shared amongst several services and clients then that's one assembly, etc.

Doing this eliminates the need to expose metadata and I think it'll let you do nifty stuff like hooking into the serialization events on both the server and client sides.

Answer 2

As with most things in computer science, the answer is - it depends :)

Are your data contract class relevant within the scope of only one, two sevices, or whole enterprise? Are they likely to change? Think about these kinds of questions.

If you do want to go for making them part of a global assembly, and you're using .NET 3.5 Sp1 know that you no longed need DataContract/DataMember attribute on your data classes. It may be useful, if you don't want to have dependency on System.ServiceModel (and in most cases you don't).

Answer 3

The folks over at IDesign.net recommend sharing contract assemblies across projects. I personally recommend this over creating proxies for everything. There's really not a compelling reason not to.

It's important to make sure your concerns are separated here. Your proposed assembly should contain only types and not any implementation, lest ye be plagued by redistributing DLLs on a more frequent basis.

I would also recommend that you group contracts that will version together into assemblies, rather than one monolithic assembly. This will reduce your overhead when making very small changes to your enterprise-level contracts.