Бизнес-логика в объекте данных против связывания против DTO (против?)

Question

У меня есть набор бизнес-классов / классов домена (для календаря), которые будут представлены в общедоступном API. В том же API есть объекты данных, которые напрямую отражают базовую структуру базы данных (отображение NHibernate, но это неважно).

Что мне нужно сделать, так это создать типизированные коллекции этих объектов, поэтому дни в календаре могут содержать набор встреч, напоминаний и т. Д., Которые поступают из базы данных.

Одним из решений является «пометка» каждого объекта данных с помощью интерфейса маркера из модели предметной области:

public class CalendarAppointment : PersistentEntity, ICalendarObject

Но затем я включил модель бизнеса / предметной области в свою модель данных.

Другое решение состоит в том, чтобы обернуть классы модели данных следующим образом и показать / использовать их в API календаря:

public class Appointment : CalendarAppointment, ICalendarObject

Но это вводит очень очевидную связь.

Третье решение состоит в том, чтобы использовать DTO, но мне нужно было бы выставить каждое поле в объекте данных в DTO ... так что, кажется, не имеет смысла создавать DTO в первую очередь. *

Какой вариант здесь лучший или есть лучший вариант?

Это проект .NET 2.0, если это имеет значение.

Answer 1

Мы решили, что объекты календаря неявно привязаны к базе данных, поэтому такая связь будет в порядке. В итоге мы выбрали решение № 4 (инкапсуляция FTW):

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

Answer 2

Всегда соблазнительно обходить DTO, когда ваша модель бизнес-области и модель данных выглядят очень похожими.

Рассматривали ли вы переработку своего публичного API, чтобы он на самом деле не выглядел "многословно"?

Если вы не можете этого сделать, перекусите и отправляйтесь в DTO, поскольку цена отправки объектов NHibernate в код клиента с использованием вашего API обычно оплачивается кровавыми слезами.