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

EF4和dapper是不同的工具，具有不同的目标和不同的功能。事实上，像EF这样的dapper和工具并肩工作是很常见的（有时甚至针对同一个对象模型）——尤其是当你没有使用项目符号中列出的所有东西时；例如，许多"显示"代码（向用户显示页面等）往往不使用这些东西。对于只读代码，在dapper实现中切换有时会非常简单，令人尴尬——只需编写一些SQL即可。

然而！当谈到确实使用了您提到的功能的代码时，这是一个更根本的变化；与其说是"迁移"，不如说是"重新实现"。如果没有更改跟踪之类的东西，您自己的代码需要更清楚地了解每个流程正在执行的操作。IMO，这实际上是一件好事，但对现有的代码库进行改造并非易事。如果从scratch（或：现有模型中的新表等）开始，通常非常容易。

就我个人而言，我在这里会采取的方法是首先来查看您的关键数据获取操作（尤其是高频、复杂查询或大容量），并考虑是否可以用基于dapper的读取操作来取代它们，尤其是如果是只读的。你可能会用最少的工作量获得一些巨大的胜利。分析将是重要的，像迷你分析工具可能会有所帮助。我不会亲自开始为它的其余部分剥离现有的工作数据层——这似乎是为了它而发明工作；这将是复杂的（交换ORM是而不是一件小事）。

然而，我会认真考虑更新到EF的最新版本；p

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

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

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

在我公司的一些项目中，我们将Dapper与成熟的NHibernate材料并排使用，它确实有效。尤其是在报告和批处理中，当您可能希望调用存储过程而不是简单的CRUD操作时。

如果你决定走这条路，我建议你考虑使用"工作单元"模式来启用EF和Dapper在同一个数据库连接上工作（我前段时间在博客中谈到过这件事）。

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