3

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

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

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

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

  1. 自动模式更新（我们相信对象设计驱动数据库结构而不是相反，这大大简化了软件部署）
  2. 如何实现继承的两个选项（同表或一对一的表关系）
  3. 支持内存存储（尽管我认为我们可以在单元测试中将 LINQ 替换为对象）
  4. 存储提供程序自定义（允许我们向 XPO 查询添加 NOLOCK 支持）

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

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

4

2 回答 2

2

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

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

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

谢谢，

于 2010-03-12T08:50:32.740 回答