在业务对象和 DTO 之间共享内容

Question

全部，

我对中型 WCF 服务的典型方法是：

1. 使用 WCF 数据协定和服务操作定义接口。数据合约将是没有 CRUD 或域逻辑的 POCO DTO。
2. 使用功能齐全的业务对象为域建模。
3. 提供一些从 DTO 到 BO 的机制，反之亦然（请参阅相关问题：Pattern/Strategy for creating BOs from DTOs）

现在，很多时候（如果不总是）业务对象和 DTO 的数据内容几乎相同。人们如何看待创建由 BO 和 DTO 共享的内容对象库。例如。如果我们有一个 WibbleDTO 和一个 WibbleBO，我们可以创建一个两者都实现的 IWibbleContent 接口。我们甚至可以创建一个 IWibbleContent 接口和一个 DTO 和 BO 都引用的 WibbleContent 类。

所以，具体问题：

1. 您是否曾在您的 DTO 和 BO 之间共享内容/数据接口？
2. 您是否曾经在您的 DTO 和 BO 之间共享数据内容类？

如果不是，那么我猜，根据我的相关问题，我们留下了繁琐的复制代码，或者我们使用 AutoMapper 之类的东西。

感谢任何 cmets。

Answer 1

我们使用的方法与您描述的 DTO 和 BO 非常相似。

我们很少有通用接口，它们要么是非常基本的（例如，获取 BusinessId 的接口），要么是特定于某个实现的，例如。可以在客户端或服务器上进行的计算。

我们实际上只是复制属性。它们通常很琐碎，不值得分享代码。

最后，更多的代码是不同的而不是相似的。

• 我们在这些类上有很多属性，它们几乎从来都不相同。
• 大多数属性在服务器上实现为get; set;，但在客户端上实现为OnPropertyChangedEvent，这需要使用显式字段。
• 我们不会在客户端和服务器端共享太多代码。所以不需要通用接口。

即使两个类的许多属性相同，实际上也没有太多可共享的。

Answer 2

我通常创建 POCO 并在我的所有层中使用它们 - 数据访问业务到 ui。在业务层，我有一些经理来回传递 POCO。我们将研究 Entity Framework 和/或 NHibernate，所以我不确定这会将我们引向何方。

是的，我们编写了一些额外的代码，但我们保持一切精益求精。我们将 MVC 用于我们的 UI，与大多数 web 表单相比，这对我来说是天赐之物，我永远不会回去。现在我们的战斗是我们应该将 JSON 发送到 ajax 回调还是使用部分视图，后者是我们大部分时间所做的。

我们是对的吗？也许不是，但它对我们有用。这么多选择，这么少时间。