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

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; }
}