.net - データオブジェクトのビジネスロジックvs.カップリングvs.DTO（vs.？）

Question

内部で公開されているAPIで公開される一連のビジネス/ドメインクラス（カレンダー用）があります。同じAPIには、基盤となるデータベース構造を直接ミラーリングするデータオブジェクトがあります（NHibernateマッピングですが、これは重要ではありません）。

私がする必要があるのは、それらのオブジェクトの型付きコレクションを作成することです。これにより、カレンダーの各日には、データベースからの一連の予定やリマインダーなどを含めることができます。

1つの解決策は、ドメインモデルのマーカーインターフェイスを使用して各データオブジェクトに「タグ付け」することです。

public class CalendarAppointment : PersistentEntity, ICalendarObject

しかし、それから私はビジネス/ドメインモデルのものを私のデータモデルに入れました。

別の解決策は、データモデルクラスを次のようにラップし、カレンダーAPIでそれらを公開/使用することです。

public class Appointment : CalendarAppointment, ICalendarObject

しかし、これは非常に明白な結合をもたらします。

3番目の解決策はDTOを使用することですが、DTOのデータオブジェクトのすべてのフィールドを公開する必要があります...そのため、最初にDTOを作成することは意味がないようです。

ここで最良のオプションはどれですか、それともより良いオプションがありますか？

これが違いを生むのであれば、これは.NET2.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