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

Question

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

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

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

public class CalendarAppointment : PersistentEntity, ICalendarObject

但是后来我将业务/域模型的东西放入我的数据模型中。

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

public class Appointment : CalendarAppointment, ICalendarObject

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

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

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

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

score 0 · Accepted Answer

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

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

score 0 · Accepted Answer

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

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

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

2 回答 2