wcf - 将 DataContract 对象与 WCF 服务中的 "Domain"对象分开是一种好的做法吗？

Question

我目前正在参与一个项目，在该项目中我们托管一个 WCF 服务以供某些客户端访问。 WCF 解决方案分为 4 个不同的 C# 项目:

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

加入这个项目后，我立即想知道为什么有一个单独的“DataContract”对象项目和一个“Model”对象项目。这两个项目基本上包含相同对象的重复项。例如，在 DataContract 项目中，有一个具有 4 个属性的 Customer 对象，模型项目也有一个具有相同四个属性的 Customer 对象...我注意到在应用程序代码将数据接触对象映射到模型对象，然后在流经我们典型的服务存储库模式时将模型对象重新映射回数据契约对象。在该服务中产生结果所需的映射数量变得非常烦人。

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

我觉得这种做法有点没有必要。难道我们不能取消数据契约项目，并将我们的模型对象用于服务端的域逻辑以及数据契约吗？

谁来教教我...

Answer 1

Couldn't we just do away with the datacontracts project and use our model objects for both domain logic on the service side and also as datacontracts?

是的，您实际上可以将域对象公开到您的服务之外，并且它可能会为您节省一两个映射。

但是，让我们想象一下， future 领域模型会根据业务需求而发生变化。

• 现有消费者对他们的契约(Contract)感到满意，并且不希望每次发布时都进行更改，因此您仅限于一个小的 non-breaking您可以进行的可能更改的子集，或者您必须等到它们准备好发布后才能进行。

• 有一天，另一位企业消费者出现，他想要利用您的域功能。但他们不想要与现有消费者相同的契约(Contract)。您如何才能在不破坏现有消费者的情况下为他们提供他们想要的东西？

• 另一个开发团队想要在进程中使用您的域模型，因此您向他们提供了一个程序集，但他们的部署服务器是 .net 2.0，因此尝试加载 System.Runtime.Serialization.dll 失败了

更一般地说，当您与外部依赖者紧密相连时，如何发展您的领域能力？

如果您认为这些情况都不适合您，并且您的服务将永远是存储库上的一个简单外观，用于某些古老且不变的业务功能，那么就去做吧。

或者，

您觉得烦人的映射可以保护您免受不可避免的变化的影响。作为服务的使用者，与该服务的发布计划耦合是一场噩梦，而且这两种方式都是如此。这些映射使您能够按照自己的意愿发展域的业务能力，而不必担心破坏任何内容。想要重命名字段吗？做吧。厌倦了那种庞大的单一类(class)？将其重构为子类型。世界是你的牡蛎。

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

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

datacontracts should not contain domain logic and that they are strictly objects to be used to send over the wire

对我来说听起来很聪明。更多 here .

如果您发现映射很乏味，我使用了 Omu ValueInjector之前，它省去了很多麻烦。