I've got a set of business/domain classes (for a calendar) that are going to be exposed in an internally-public API. In the same API, there are data objects that directly mirror the underlying database structure (NHibernate mapping, but that's unimportant).
What I need to do is build typed collections of those objects, so the days on the calendar can each contain a set of appointments, reminders, etc., which come from the database.
One solution is to "tag" each data object using a marker interface from the domain model:
public class CalendarAppointment : PersistentEntity, ICalendarObject
But then I've put business/domain model stuff in with my data model.
Another solution is to wrap the data model classes as follows, and expose/use those in the calendar API:
public class Appointment : CalendarAppointment, ICalendarObject
But this introduces very obvious coupling.
A third solution is to use a DTO, but I would need to expose every field in the data object in the DTO... so it doesn't seem to make sense to create a DTO in the first place.
Which is the best option here, or is there a better option?
This is a .NET 2.0 project, if that makes a difference.
We decided that the calendar objects are implicitly tied to the database, so that kind of coupling would be okay. We ended up going with solution #4 (encapsulation FTW):
public class Appointment : ICalendarObject
{
public CalendarAppointment Item { get; }
}