从XPO迁移到LINQ到SQL的提示

Question

我是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吗？它看起来比我们需要的任何东西都复杂得多。

Answer 1

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

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

Answer 2

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

谢谢，