私の経験から、.NET の主要な ORM フレームワーク ( NHibernate、LinqToSql、Entity Framework ) は、読み込まれたオブジェクトを追跡するときに最適に機能します。これは単純なクライアント/サーバー アプリケーションでは問題なく機能しますが、サービス指向アーキテクチャで Web サービスを含む 3 層以上のアーキテクチャを使用する場合、これは不可能です。最終的には、自分で追跡を行うコードをたくさん書くことで実現できますが、ORM は DB アクセスを簡素化するためのものではないでしょうか。
サービス指向アーキテクチャで ORM を使用するという考えは、まったく良いのでしょうか?
LLBLGen Proには、エンティティ内の変更追跡があります。これは、プリフェッチパス（グラフノードごとに1つのクエリ）を使用してデータベースからグラフをフェッチし、それをネットワーク経由でクライアントにシリアル化し、そこで変更して送り返し、すべての変更追跡が内部にあるため、グラフを直接保存できることを意味しますエンティティ（およびコンパクトなカスタム要素としてXML内でシリアル化されます）。
免責事項：私はllblgenproのリード開発者です。
「SOA」の意味によって異なります。サービス コントラクトでドメイン オブジェクトを公開することが適切なサービス設計となることはめったにありません。内部の実装の詳細が公開され、公開されたコントラクトが変更される可能性が高くなり、バージョン管理が非常に困難になります。
サービス エンドポイント用のカスタム メッセージ ドキュメント (WCF DataContracts など) を作成する場合、ORM を使用してサービスを実装するのは比較的簡単です。通常、データベースからドメイン オブジェクトを再読み込みし、変更されたプロパティをマップ (またはメソッドを呼び出し) してから、変更を永続化します。
サービスのほとんどが CRUD メソッドである場合、カスタム メッセージは実質的に DTO になります。オプティミスティック コンカレンシーとドメイン オブジェクト マッピングを手動で管理する必要があります。
更新:これは古い回答であるため、EF4にはエンティティの変更追跡も含まれるようになったことを指摘したいと思います。これはサービス コントラクトの設計としては不十分であると私は今でも主張していますが、分散アプリケーション フレームワークを検討している場合は、おそらく適切なオプションです。
DataObjects.Netの今後の同期と切断されたセットの説明を見てください。
分散オブジェクトをアーキテクチャ パターンとして使用するのをやめることをお勧めします。メッセージング アーキテクチャや RESTful スタイルほど効果的ではありません。
メッセージの内外でのデータ転送のオーバーヘッドが気に入らない場合は、REST を検討することをお勧めします。ただし、ADO.NET データ サービスのように REST ではなく、HTTP 経由でオブジェクトを分散するだけです。
REST は、サーバー上で醜い (ただし機械で読み取り可能な) UI を公開し、クライアントを使用して見栄えを良くすることに関するものです。REST では、クライアントのドメイン エンティティに関する知識がないため、それらをネットワーク経由で送信する必要はありません。
ORM フレームワークは、データベースと直接やり取りする場合にのみ役立ちます。サービス指向アーキテクチャであっても、ORM は最終層をプログラミングする際の負荷を軽減するのに役立ちます。サービス部分を処理するには、WCFなどの他の手法が必要になります。ORM とサービスを統合している人はまだ知りませんが、エンティティやDataContracts と同じクラスに注釈を付けるのは簡単です。
SignumFrameworkには、エンティティ内でも追跡機能があります。また、完全な Linq プロバイダーもありますが、新しいデータベースのみで動作するように設計されています (反対側ではなく、C# エンティティからスキーマを生成します)。
変更追跡: http://www.signumframework.com/ChangeTracking.ashx
免責事項: 私は Signum Framework の主任開発者です :)
NHibernate で memcached を 2 番目のレベルのキャッシュとして使用できます。