views:

641

answers:

2

I'm a long-time user of the DevExpress XPO library. It has many great features, but there are a few weaknesses:

  1. When saving an existing object, all properties are sent in an update query; changes are tracked on a per-object basis, not per-property.
  2. Optimistic locking is done on a per-object basis, rather than per-column.
  3. 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.
  4. 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:

  1. Automatic schema updates (we believe in object design driving database structure rather than the reverse, and this greatly simplifies software deployment)
  2. Two options for how inheritance is implemented (same-table or one-to-one table relationships)
  3. Support for in-memory storage (though I suppose that we could substitute LINQ to Objects in our unit tests)
  4. 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.

+2  A: 

I'm sad that I didn't get any answers from the community, but here's my thoughts so far. I've had a chance to try out LINQ to SQL and ADO.NET Entity Framework for a while on different projects, and I feel that ADO.NET Entity Framework would better fill our needs. As far as the XPO-specific features I was hoping to keep:

  1. Automatic schema updates will have to go once we convert. It's a minor annoyance, but there are a few benefits to maintaining this separately.
  2. ADO.NET Entity Framework has a lot of data mapping options; the different inheritance models appear to be supported.
  3. For in-memory storage, I'm still unsure how well-supported this is. There appears to be a SQLite ADO.NET provider that is compatible with the Entity Framework, and SQLite can do in-memory storage, so in theory the unit tests could use a different connection string specifying the in-memory database. Hopefully it's that easy; otherwise, writing unit tests will be pretty hard to do without a lot of work (abstracting out a repository interface, etc).
  4. I haven't looked into provider customization yet. I've tried to architect the system such that we won't have as much data shared among services as before, so maybe we won't need all those WITH (NO LOCK) statements that I needed in previous systems. Or maybe SQL Server 2008 has improved its locking mechanisms so that we won't encounter the same locking issues.
Jacob
A: 

Hi Jacob,

So you did migrate your application from XPO to Linq2Sql, didn't you? I've been playing with XPO as part of XAF too, honestly I prefer Linq2Sql/EF to XPO but since it is tightly coupled in XAF so I don't have other choice. We're going to use XAF to speed up UI implementation of a our product, I think XAF does its work quite well, but I'm really worried about XPO.

Thanks,

Tiendq
I didn't get a chance to migrate it, and now I'm at a different company. However, I've used EF in future products and have been pretty happy with that. I wouldn't worry too much about XPO. Most of my problems stemmed from using it in a web environment with high concurrency and threading. If you're using this with the XAF, I'm assuming it's a single-threaded application with low concurrency. Just be aware of how optimistic locking works from the start and you should be fine.
Jacob
Yes, it is a Winform business application and single-threaded so I'm little worried about concurrency. I've been playing with XAF for several days and it's optimistic locking is good enough for my situation, but not really optimal. Nonetheless, XAF has been developed for years so it has to deal with its legacy code.
Tiendq