我目前是一个项目的一部分，我们托管一个WCF服务，供某些客户访问。 WCF解决方案分为4个不同的C＃项目：
Host.csproj
DataContracts.csproj
Infrastructure.csproj
Model.csproj
加入这个项目后，我立即想知道为什么“DataContract”对象有一个单独的项目，“Model”对象有一个项目。这两个项目基本上包含相同对象的副本。例如，在DataContract项目中，有一个Customer对象具有4个属性，并且模型项目也有一个Customer对象具有相同的四个属性...我注意到有很多自动化器（映射）用于应用程序代码将datacontact对象映射到模型对象，然后在流经我们典型的服务存储库模式时将模型对象重新映射回数据协定对象。在此服务中产生结果所需的映射数量变得非常烦人。
在向一些队友询问为什么选择此路线之后，我被告知数据交换不应包含域逻辑，并且它们是用于通过线路发送的严格对象（并且所有域逻辑都应该使用模型完成）对象的版本）。
我觉得这种做法有点不必要。难道我们不能放弃datacontracts项目并将我们的模型对象用于服务端的域逻辑以及数据交换吗？
有人开导我......
答案 0 :(得分：8)
我们不能取消datacontracts项目并使用我们的 为服务端的域逻辑建模对象，也为 datacontracts？
是的，您可以将您的域对象暴露在服务之外，并且可能会为您节省一两个映射。
但是，让我们想象未来域模型会根据业务需求而变化。
现有的消费者对他们的合同感到满意，并且不希望每次发布时都需要更改，因此您只能进行一小部分non-breaking可能的更改，或者你必须等到他们准备好发布之前你就可以了。
有一天，另一位想要利用域名功能的商业消费者出现了。但他们不希望与现有消费者签订同样的合同。如何在不打破现有消费者的情况下为他们提供他们想要的东西？
另一个开发团队希望在进程中使用您的域模型，因此您向他们发送程序集，但他们的部署服务器是.net 2.0，因此它试图加载System.Runtime.Serialization.dll
更一般地说，当您与外部家属进行硬连线时，如何改进域名功能？
如果您认为这些情况都不适用于您，并且您的服务将始终永远是存储库中的一个简单的外观，用于一些古老而不变的业务功能，那就去吧。
或者，
你发现有刺激性的映射可以保护你免受不可避免的变化。作为服务的消费者，与服务的发布时间表相结合是一场噩梦，两种方式都是如此。这些映射使您可以随心所欲地发展您的域名业务功能，而无需担心破坏任何内容。想要重命名一个字段？做吧。厌倦了那个庞大的单班？将其重构为子类型。世界就是你的牡蛎。
如果您担心效率或性能，则进程内类型映射比进程外服务调用快几个数量级，几乎可以忽略不计。
所以我不得不说出你同事给你的建议：
datacontracts不应包含域逻辑和它们 用于通过电线发送的严格对象
对我来说听起来很聪明。还有更多here。
如果您发现这些映射很乏味，我之前使用过Omu ValueInjector并且需要很多麻烦。