I'm a long-time user of the DevExpress XPO library. It has many great features, but there are a few weaknesses:
- When saving an existing object, all properties are sent in an update query; changes are tracked on a per-object basis, not per-property.
- Optimistic locking is done on a per-object basis, rather than per-column.
- When an optimistic locking exception occurs, no context is provided describing the nature of the conflict; your only real response is to fail the operation or reproduce it and try again in a loop.
- LINQ support for XPQuery is very weak (at least in 8.1, which we're using). Thus, you're often forced to use XPView, which is not type-safe, or XPCollection, which can be returning columns you don't necessarily need.
After reading about how LINQ to SQL implements optimisting locking and handling update conflicts, I was sold! I like how it implements column-level optimistic locking and doesn't need to add a column to the table. Being able to inspect and handle the exact nature of conflicts is great. And the fact that they track per-column changes should make its update queries much more efficient.
Of course, I haven't yet used LINQ to SQL in real applications, so I don't know it compares in reality. Also, I'm unclear on if it has analogs for some of the features we enjoy with XPO, such as:
- Automatic schema updates (we believe in object design driving database structure rather than the reverse, and this greatly simplifies software deployment)
- Two options for how inheritance is implemented (same-table or one-to-one table relationships)
- Support for in-memory storage (though I suppose that we could substitute LINQ to Objects in our unit tests)
- Storage provider customization (that allowed us to add NOLOCK support to our XPO queries)
We're going to be doing an exploratory partial migration where we will be temporarily using the two ORMs for different parts of our code. Have any of you had real-world experience with both XPO and LINQ to SQL? How do they compare in practice? Specifically, do you know of any features that LINQ to SQL lacks that would provide challenges to a code migration?
Oh, and should I even care about LINQ to Entities? It looks far more complicated than anything we need.