在企业级程序集中定义 DataContracts 然后在 WCF 服务项目中引用它们而不是在单个 WCF 服务解决方案级别定义它们是一种好习惯吗？我看到的所有 WCF 示例都避开了该主题，并且仅在服务解决方案中定义了 DataContracts。我与之交谈的一些程序员希望将 DataContracts 视为企业级规范数据模型的不同风格，而不是服务本地合同。我还没有找到任何支持或反对这种观点的论据。
这个问题可能很难选择正确的答案，但我会努力的。我至少会对任何我觉得能增加我对这个话题的理解的东西投赞成票。
我真的很喜欢将 DataContracts（和服务合同）放入程序集中，然后与服务和客户端等共享它们的想法，但我认为没有任何充分的理由将它们全部放入一个整体程序集中。
根据它们的使用方式将它们放入程序集中更有意义。如果有一组在多个服务和客户端之间共享，那么这就是一个程序集，等等。
这样做消除了暴露元数据的需要，我认为它可以让你做一些漂亮的事情，比如在服务器端和客户端连接到序列化事件。
IDesign.net 上的人们建议跨项目共享合同程序集。我个人建议不要为所有内容创建代理。真的没有令人信服的理由不这样做。
确保您的关注点在这里分开很重要。你提议的程序集应该只包含类型而不是任何实现，以免你被更频繁地重新分发 DLL 所困扰。
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.
与计算机科学中的大多数事情一样，答案是 - 这取决于:)
您的数据合同类别是否仅在一项、两项服务或整个企业范围内相关？他们有可能改变吗？想想这类问题。
如果您确实想让它们成为全局程序集的一部分，并且您使用的是 .NET 3.5 Sp1，请知道您不再需要数据类上的 DataContract/DataMember 属性。如果您不想依赖 System.ServiceModel （并且在大多数情况下您不需要），它可能很有用。