linq-to-sql - 从 XPO 迁移到 LINQ to SQL 的提示

Question

我是 DevExpress XPO 库的长期用户。它有很多很棒的功能，但也有一些弱点:

1. 保存现有对象时，所有属性都在更新查询中发送；更改是基于每个对象而不是每个属性进行跟踪的。
2. 乐观锁定是在每个对象的基础上完成的，而不是每个列。
3. 当发生乐观锁定异常时，不提供描述冲突性质的上下文；您唯一真正的 react 是使操作失败或重现它并在循环中重试。
4. LINQ 对 XPQuery 的支持非常弱(至少在我们使用的 8.1 中)。因此，您经常被迫使用类型不安全的 XPView 或 XPCollection，后者可能会返回您不一定需要的列。

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

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

1. 自动架构更新(我们相信对象设计驱动数据库结构而不是相反，这大大简化了软件部署)
2. 关于如何实现继承的两种选择(同表或一对一表关系)
3. 支持内存存储(尽管我想我们可以在单元测试中用 LINQ to Objects 代替)
4. 存储提供商定制(允许我们向 XPO 查询添加 NOLOCK 支持)

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

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

Answer 1

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

1. 一旦我们转换，就必须进行自动模式更新。这是一个小麻烦，但单独维护它有一些好处。
2. ADO.NET Entity Framework 有很多数据映射选项；似乎支持不同的继承模型。
3. 对于内存存储，我仍然不确定它的支持程度如何。似乎有一个与 Entity Framework 兼容的 SQLite ADO.NET 提供程序，并且 SQLite 可以进行内存存储，因此理论上单元测试可以使用不同的连接字符串来指定内存数据库。希望就这么简单；否则，如果不进行大量工作(抽象存储库接口(interface)等)，编写单元测试将非常困难。
4. 我还没有研究提供程序定制。我已经尝试构建系统，以便我们不会像以前那样在服务之间共享那么多数据，所以也许我们不需要所有那些 WITH (NO LOCK) 我需要的语句以前的系统。或者 SQL Server 2008 改进了它的锁定机制，这样我们就不会遇到相同的锁定问题。