Logique métier dans un objet de données vs couplage par rapport à DTO (vs.?)

Question

J'ai un ensemble de classes métier/domaine (pour un calendrier) qui vont être exposées dans une API publique interne. Dans la même API, il y a des objets de données qui reflètent directement la structure de base de données sous-jacente (NHibernate mapping, mais ce n'est pas important). Ce que je dois faire est de construire des collections typées de ces objets, ainsi les jours sur le calendrier peuvent chacun contenir un ensemble de rendez-vous, de rappels, etc., qui viennent de la base de données.

Une solution consiste à « marquer » chaque objet de données en utilisant une interface marqueur du modèle de domaine:

public class CalendarAppointment : PersistentEntity, ICalendarObject

Mais j'ai mis des choses de modèle d'affaires/domaine avec mon modèle de données.

Une autre solution consiste à envelopper les classes de modèle de données comme suit, et exposer/utiliser celles de l'API civile:

public class Appointment : CalendarAppointment, ICalendarObject

Mais ce couplage introduit très évident.

Une troisième solution consiste à utiliser un DTO, mais j'aurais besoin d'exposer chaque champ dans l'objet de données dans le DTO ... il ne semble donc pas logique de créer un DTO en premier lieu.

Quelle est la meilleure option ici, ou y at-il une meilleure option?

Ceci est un projet .NET 2.0, si cela fait une différence.

Answer 1

Nous avons décidé que les objets du calendrier sont implicitement liés à la base de données, de sorte que ce type de couplage serait correct. Nous avons fini par aller avec la solution # 4 (encapsulation FTW):

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

Answer 2

Il est toujours tentant de contourner les DTO lorsque votre modèle de domaine d'activité et votre modèle de données sont terriblement similaires.

Avez-vous envisagé de retravailler votre API publique pour qu'elle ne soit pas vraiment "verbeuse"?

Si vous ne pouvez pas vraiment faire cela, mordez la balle et allez DTO, car le prix de l'envoi d'objets NHibernate au code client en utilisant votre API est généralement payé en larmes de sang.