だから、私は素晴らしいドメインモデルを構築しました。リポジトリはデータアクセスとそうでないものを処理します。理由を削除とともにログに記録する必要があることを示す新しい要件がポップアップ表示されました。これまで、削除はかなり単純でした=> Entity.Children.Remove（child）。ORMツールが状態管理を処理していたため、内部変更の追跡は行われませんでした。ただし、これをどのように処理するかは正確にはわかりません。
1）削除された子コレクションを親エンティティに保持し、変更追跡をnHibernateから引き出して、自分で処理することができます。
2）??????
わかりました、これはクレイジーに聞こえますが、nHibernate の使い方が悪いために叩かれるかもしれませんが、これについてもう一度考えてみます。削除する前に、削除する子を選択して (ID は既に正しいですか?)、削除をテーブルに記録するために使用するエンティティに変換してください。エンティティに理由を追加して保存し、削除を続行します。最良の部分は、変換の結果に汎用エンティティ、つまり「auditInfo」を使用でき、トランザクション内で実行できるため、何かが失敗した場合にすべてをロールバックできます! OK、クレイジーかもしれませんがクリエイティブですよね？
その特定のエンティティ タイプの削除が比較的まれな場合は、エンティティにフラグを追加して、実際に行を削除するのではなく、論理的に「削除済み」としてマークします。アプリケーションは、通常の状況下でこれらのエンティティの非表示を処理する必要があります。
これにより、許容できない数の「古い」行が発生する場合は、ワトソンの回答に似たものをお勧めします。正確な要件によっては、削除されたデータと追加の「理由」フィールドをアプリケーションから直接ログに記録することでおそらく回避できます。インターセプターを使用すると、監査の観点からはより透過的で快適になりますが、個別の削除ログ (テーブル、データベース、ファイル) の方がおそらく簡単です。
IInterceptor インターフェイスを実装し、onDelete 機能をオーバーライドして、必要な情報をエンティティから取得し、削除する前にロガーに送信できますか (もちろん NHibernate を使用)。