Linq to sql 从XPO到LINQ再到SQL的迁移技巧

我是DevExpress XPO库的长期用户。它有许多很棒的特性，但也有一些缺点：

保存现有对象时，在更新查询中发送所有属性；更改是按对象跟踪的，而不是按属性跟踪的

乐观锁定是基于每个对象而不是每列进行的

当乐观锁定异常发生时，不提供描述冲突性质的上下文；您唯一真正的反应是操作失败或重新生成操作，然后在循环中重试

LINQ对XPQuery的支持非常弱（至少在我们使用的8.1中是如此）。因此，您经常被迫使用XPView（它不是类型安全的）或XPCollection（它可以返回您不一定需要的列）

在阅读了LINQtoSQL如何实现优化锁定和处理更新冲突后，我被说服了！我喜欢它实现列级乐观锁定的方式，并且不需要向表中添加列。能够检查和处理冲突的确切性质非常重要。而且，它们跟踪每列更改的事实应该使其更新查询更加高效

当然，我还没有在实际的应用程序中使用LINQ到SQL，所以我不知道它在实际应用中是否可以比较。此外，我不清楚它是否与我们喜欢的XPO的某些功能类似，例如：

自动模式更新（我们相信对象设计驱动数据库结构，而不是相反，这大大简化了软件部署）

如何实现继承的两个选项（相同的表或一对一的表关系）

支持内存存储（尽管我认为我们可以在单元测试中将LINQ替换为对象）

存储提供商定制（允许我们向XPO查询添加NOLOCK支持）

我们将进行一次探索性的部分迁移，暂时将这两种ORM用于代码的不同部分。你们中有谁在XPO和LINQtoSQL方面都有实际经验吗？它们在实践中如何比较？具体地说，您知道LINQ到SQL缺少哪些特性会给代码迁移带来挑战吗

---

哦，我应该关心LINQ to实体吗？这看起来比我们需要的任何东西都要复杂得多。

我很难过，因为我没有从社区得到任何答案，但以下是我目前的想法。我曾经有机会在不同的项目上试用过LINQtoSQL和ADO.NET实体框架，我觉得ADO.NET实体框架可以更好地满足我们的需求。就我希望保留的XPO特定功能而言：

一旦我们转换，自动模式更新将不得不进行。这是一个小麻烦，但是单独维护它有一些好处

NET实体框架有很多数据映射选项；似乎支持不同的继承模型

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

我还没有研究提供者定制。我已经尝试构建系统，这样我们就不会像以前那样在服务之间共享那么多数据，所以我们可能不需要以前的系统中需要的所有带有（无锁）语句的

。或者SQLServer2008已经改进了它的锁定机制，这样我们就不会遇到同样的锁定问题

---

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

---

谢谢，

只是好奇，您也看过DB4Objects吗？我不知道db4o中的锁定方案，但很想知道您是否对其进行了评估。（虽然它是一个真正的OODBMS，但它不是ORM）不，我没有研究过DB4Objects。因为我们依赖于SSAS，所以改变数据库引擎对我们来说并不是一个真正的选择。我想了解一下您是如何发现LinqToSql与XPO的。还是你走了另一条路？--AlexI将发布我自己问题的答案，只是想对>>1发表评论。保存现有对象时，所有属性都会在更新查询中发送；更改是按对象跟踪的，而不是按属性跟踪的。我没有机会迁移它，现在我在另一家公司。然而，我已经在未来的产品中使用了EF，并且对此非常满意。我不会太担心XPO。我的大多数问题都源于在具有高并发性和线程的web环境中使用它。如果您在XAF中使用它，我假设它是一个低并发性的单线程应用程序。只要从一开始就知道乐观锁定是如何工作的，你应该很好。是的，它是一个Winform业务应用程序，并且是单线程的，所以我不太担心并发性。我已经和XAF打了好几天了，乐观地说，锁定对我的情况来说已经足够好了，但并不是最理想的。尽管如此，XAF已经开发了多年，因此它必须处理其遗留代码。