从WCF服务中的"域"对象中分离DataContract对象是一种好习惯吗？

Question

我目前是一个项目的一部分,我们托管一个WCF服务,供某些客户访问.WCF解决方案分为4个不同的C#项目:

Host.csproj
DataContracts.csproj
Infrastructure.csproj
Model.csproj

加入这个项目后,我立即想知道为什么有一个单独的"DataContract"对象项目和一个"模型"对象项目.这两个项目基本上包含相同对象的副本.例如,在DataContract项目中,有一个Customer对象具有4个属性,并且模型项目也有一个Customer对象具有相同的四个属性...我注意到有很多自动化器(映射)用于应用程序代码将datacontact对象映射到模型对象,然后在流经我们典型的服务存储库模式时将模型对象重新映射回数据协定对象.在此服务中产生结果所需的映射数量变得非常烦人.

在向一些队友询问为什么选择这条路线之后,我被告知数据交换不应该包含域逻辑,并且它们是用于通过线路发送的严格对象(并且所有域逻辑都应该使用模型版本来完成)宾语).

我觉得这种做法有点不必要.难道我们不能放弃datacontracts项目并将我们的模型对象用于服务端的域逻辑以及数据交换吗？

有人开导我...

Answer 1

难道我们不能放弃datacontracts项目并将我们的模型对象用于服务端的域逻辑以及数据交换吗？

是的,您实际上可以将域对象暴露在服务之外,它可能会为您节省一两个映射.

但是,让我们想象一下,未来域模型会根据业务需求而变化.

• 现有的消费者对他们的合同感到满意,并且不希望每次发布都需要更改,因此您只能在可以做出的一些小的不间断的更改中进行更改,或者您必须等待他们准备好在你可以之前发布.

• 有一天,另一个想要利用您的域功能的商业消费者出现了.但他们不希望与现有消费者签订同样的合同.如何在不打破现有消费者的情况下为他们提供他们想要的东西？

• 另一个开发团队希望在进程中使用您的域模型,因此您向他们发送程序集,但他们的部署服务器是.net 2.0,因此它试图加载System.Runtime.Serialization.dll

更一般地说,当您与外部家属硬连线时,如何改进您的域功能？

如果您认为这些情况都不适用于您,并且您的服务将始终永远是存储库中的一个简单的外观,用于一些古老而不变的业务功能,那就去吧.

要么,

您发现令人恼火的映射可以保护您免受不可避免的变化.作为服务的消费者,与该服务的发布时间表相结合是一场噩梦,两种方式都是如此.这些映射使您能够根据需要发展域名的业务功能,而无需担心破坏任何内容.想要重命名一个字段？做吧.厌倦了那个庞大的单班？将其重构为子类型.世界是你的牡蛎.

如果您担心效率或性能,则进程内类型映射比进程外服务调用快几个数量级,几乎可以忽略不计.

所以我将不得不说出你同事给你的建议:

datacontracts不应包含域逻辑,并且它们是用于通过线路发送的严格对象

听起来很聪明.这里还有很多.

如果你发现映射很繁琐,我之前使用过Omu ValueInjector,这需要很多麻烦.