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