数据对象中的业务逻辑与耦合与 DTO（与？）答案

【问题标题】：Business logic in a data object vs. coupling vs. DTO (vs. ?)数据对象中的业务逻辑与耦合与 DTO（与？）
【发布时间】：2010-12-04 15:41:27
【问题描述】：

我有一组将在内部公共 API 中公开的业务/域类（用于日历）。在同一个 API 中，存在直接反映底层数据库结构的数据对象（NHibernate 映射，但这并不重要）。

我需要做的是构建这些对象的类型化集合，因此日历上的每一天都可以包含一组来自数据库的约会、提醒等。

一种解决方案是使用域模型中的标记接口“标记”每个数据对象：

public class CalendarAppointment : PersistentEntity, ICalendarObject

但是我已经将业务/领域模型的东西放入我的数据模型中。

另一种解决方案是将数据模型类包装如下，并在日历 API 中公开/使用它们：

public class Appointment : CalendarAppointment, ICalendarObject

但这引入了非常明显的耦合。

第三种解决方案是使用 DTO，但我需要在 DTO 中公开数据对象中的每个字段......所以首先创建 DTO 似乎没有意义。

这里哪个是最好的选择，还是有更好的选择？

这是一个 .NET 2.0 项目，如果有区别的话。

【问题讨论】：

【解决方案1】：

当您的业务域模型和数据模型看起来非常相似时，绕过 DTO 总是很诱人。

您是否考虑过重新设计您的公共 API，使其看起来不那么“冗长”？

如果你真的不能做到这一点，那就硬着头皮去 DTO，因为使用你的 API 将 NHibernate 对象发送到客户端代码的代价通常是血泪。

【讨论】：

我应该澄清一下，我会编辑我的问题。我所说的 API 将在内部公开——计划是它将用于开发我们的基础产品，并扩展基础产品的功能（这是遗留系统迁移的一部分，其中几个客户拥有巨大的与基本产品的偏差）。我们已经将数据结构类（如上）从数据层查询中分离出来，但这两个东西都必须在 API 中公开。

【解决方案2】：

我们决定将日历对象隐式绑定到数据库，因此这种耦合是可以的。我们最终选择了解决方案 #4（封装 FTW）：

public class Appointment : ICalendarObject
{
    public CalendarAppointment Item { get; }
}

【讨论】：