C# 应用程序从EF4迁移到Dapper.net

我正在使用EntityFramework4开发一个大型WPF应用程序，现在客户端要求将应用程序从EF4迁移到Dapper.net。我不确定此迁移任务的可行性和业务收益，因为在Dapper中缺少EF4的以下功能：

• 变更跟踪
• 延迟加载
• 热切的吸引
• 瀑布
• 身份图
• 工作单位跟踪

---

请就这一点或WPF应用程序是否存在其他更好的micro ORM向我提出建议。

EF4和dapper是不同的工具，具有不同的目标和不同的功能。事实上，很常见的情况是，dapper和EF等工具并排工作（有时甚至针对同一对象模型），特别是当您没有使用项目符号中列出的所有内容时；例如，许多“显示”代码（向用户显示页面等）倾向于不使用这些东西。对于只读代码，在一个简洁的实现中切换有时会非常简单——只需编写一些SQL就可以了

然而！当涉及到使用您提到的特性的代码时，这是一个更基本的变化；与其说是“迁移”，不如说是“重新实现”。如果没有更改跟踪之类的东西，您自己的代码需要更清楚地了解每个流程执行的操作。在我看来，这实际上是一件好事，但在现有的代码库中进行改造并不是一件小事。如果从头开始（或者：现有模型中的新表等），通常非常容易

P>个人地，我将在这里采取的方法首先查看关键数据获取操作（特别是高频、复杂查询或大容量），并考虑它们是否可以用基于DaPER的读取操作来替换；尤其是在只读的情况下。你可以用最少的工作量获得一些巨大的胜利。分析很重要，像mini profiler这样的工具可能会有所帮助。我个人不会为了它的其余部分而撕毁现有的工作数据层——这似乎是为了它而发明工作；这将是一件复杂的事情（交换一个ORM不是一件小事）

不过，我会认真考虑更新EF的最新版本；p

---

（哦，如果这很重要的话：我是dapper的主要作者和维护者）

在我看来，关键的问题是为什么您的客户希望您将此项目迁移到另一个框架

如果她因为某些功能或模块的性能不佳而希望您执行此迁移，那么您可以采用Marc的方法，只迁移系统的关键部分

在我公司的一些项目中，我们使用整洁的设计和成熟的NHibernate产品并排使用，而且非常有效。特别是在报告和批处理中，当您可能希望调用存储过程而不是简单的CRUD操作时

如果你决定走这条路，我建议你考虑使用“工作单位”模式来实现EF。 在同一个数据库连接上工作（我很久以前就讨论过这个问题）

---

当然，您必须记住技术上的差异，比如Dapper（与EF或NH等“全面”的ORM相反）没有会话概念，只有在刷新DB更改后，才会读取EF修改的“脏”对象。

谢谢您的回复。您的意思是说，只有在只读视图中，我们才应该使用dapper&let dapper&EF并排工作。我确实需要在我的应用程序中进行并发管理和更改跟踪。请建议。@user1103378澄清：我并不是说dapper应该只用于只读视图；见鬼，在过去的几年里，几乎所有进行数据更改的新代码都使用了dapper；我想说的是，在基于ORM的更改跟踪写入和micro ORM显式写入之间进行更改（无论是哪种ORM/micro ORM）并不是一件小事。因此，我不会选择随意地或一时兴起地这样做。如果这是必须的：那么当然，这是可以做到的——但这可能是相当多的工作。