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

Question

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

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

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

public class CalendarAppointment : PersistentEntity, ICalendarObject

但是后来我将业务/领域模型的内容放入我的数据模型中。

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

public class Appointment : CalendarAppointment, ICalendarObject

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

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

这里最好的选择是什么，或者有更好的选择吗？

这是一个 .NET 2.0 项目，如果这有什么不同的话。

Answer 1

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

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

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

Answer 2

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

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