从XPO迁移到LINQ到SQL的提示

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

我是DevExpress XPO库的长期用户。它有许多很棒的功能,但也存在一些缺点:

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.

LINQ对XPQuery的支持非常弱(至少在8.1中,我们正在使用)。因此,您经常*使用不是类型安全的XPView或XPCollection,它可以返回您不一定需要的列。

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.

在阅读了LINQ to SQL如何实现优化锁定和处理更新冲突之后,我被卖了!我喜欢它如何实现列级乐观锁定,并且不需要向表中添加列。能够检查和处理冲突的确切性质是很好的。而且他们跟踪每列更改的事实应该使其更新查询更加高效。

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:

当然,我还没有在实际应用程序中使用LINQ to SQL,所以我不知道它在实际中是否比较。此外,我不清楚它是否具有我们喜欢的XPO功能的类比,例如:

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)

支持内存存储(虽然我认为我们可以在单元测试中将LINQ替换为对象)

4. Storage provider customization (that allowed us to add NOLOCK support to our XPO queries)

存储提供程序自定义(允许我们为我们的XPO查询添加NOLOCK支持)

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?

我们将进行一次探索性的部分迁移,我们将暂时将两个ORM用于代码的不同部分。你们有没有XPO和LINQ to SQL的实际经验?他们在实践中如何比较?具体来说,您是否知道LINQ to SQL缺少哪些功能会给代码迁移带来挑战?

Oh, and should I even care about LINQ to Entities? It looks far more complicated than anything we need.

哦,我应该关心LINQ to Entities吗?它看起来比我们需要的任何东西都复杂得多。

2 个解决方案

#1

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:

我很伤心,我没有从社区得到任何答案,但到目前为止,这是我的想法。我有机会在不同的项目上试用LINQ to SQL和ADO.NET Entity Framework一段时间,我觉得ADO.NET实体框架可以更好地满足我们的需求。至于我希望保留的XPO特定功能:

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.

ADO.NET Entity Framework有很多数据映射选项;似乎支持不同的继承模型。

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).

对于内存存储,我仍然不确定这是多么受支持。似乎有一个与实体框架兼容的SQLite ADO.NET提供程序,SQLite可以进行内存存储,因此理论上单元测试可以使用指定内存数据库的不同连接字符串。希望它很容易;否则,如果没有大量工作(抽象出存储库界面等),编写单元测试将非常困难。

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.

我还没有考虑提供商定制。我试图构建系统,以便我们不会像之前那样在服务之间共享那么多的数据,所以也许我们不需要在以前的系统中需要的所有WITH(NO LOCK)语句。或者SQL Server 2008可能已经改进了其锁定机制,因此我们不会遇到相同的锁定问题。

#2

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.

所以你确实将应用程序从XPO迁移到了Linq2Sql,不是吗?我一直在玩XPO作为XAF的一部分,说实话,我更喜欢Linq2Sql / EF到XPO,但因为它在XAF中紧密耦合所以我没有其他选择。我们将使用XAF来加速我们产品的UI实现,我认为XAF做得很好,但我真的很担心XPO。

Thanks,