私は DevExpress XPO ライブラリの長年のユーザーです。多くの優れた機能を備えていますが、いくつかの弱点があります。
- 既存のオブジェクトを保存すると、すべてのプロパティが更新クエリで送信されます。変更は、プロパティごとではなく、オブジェクトごとに追跡されます。
- オプティミスティック ロックは、列ごとではなく、オブジェクトごとに行われます。
- 楽観的ロック例外が発生した場合、競合の性質を説明するコンテキストは提供されません。あなたの唯一の本当の対応は、操作を失敗させるか、それを再現してループで再試行することです。
- XPQuery の LINQ サポートは非常に弱いです (少なくとも、私たちが使用している 8.1 では)。したがって、タイプセーフではない XPView や、必ずしも必要ではない列を返す可能性のある XPCollection を使用せざるを得ないことがよくあります。
LINQ to SQL がロックの最適化と更新の競合の処理を実装する方法について読んだ後、私は納得しました! 列レベルの楽観的ロックを実装し、テーブルに列を追加する必要がない点が気に入っています。競合の正確な性質を調べて処理できることは素晴らしいことです。また、列ごとの変更を追跡するという事実により、更新クエリがより効率的になるはずです。
もちろん、実際のアプリケーションで LINQ to SQL をまだ使用したことがないので、実際に比較できるかどうかはわかりません。また、XPO で楽しんでいる次のようないくつかの機能に類似したものがあるかどうかも不明です。
- 自動スキーマ更新 (私たちはオブジェクト設計がデータベース構造を逆にするのではなく駆動すると信じており、これによりソフトウェアの展開が大幅に簡素化されます)
- 継承の実装方法に関する 2 つのオプション (同一テーブルまたは 1 対 1 のテーブル リレーションシップ)
- インメモリ ストレージのサポート (単体テストで LINQ to Objects を代用できると思いますが)
- ストレージ プロバイダーのカスタマイズ (これにより、XPO クエリに NOLOCK サポートを追加できました)
コードの異なる部分に 2 つの ORM を一時的に使用する、試験的な部分的な移行を行う予定です。XPO と LINQ to SQL の両方を実際に使用した経験のある方はいますか? それらは実際にどのように比較されますか?具体的には、LINQ to SQL に欠けていて、コードの移行が困難になる機能をご存知ですか?
ああ、LINQ to Entities についても気にする必要がありますか? 必要なものよりもはるかに複雑に見えます。