我正在使用Entity framework4处理大型WPF应用程序，现在客户端要求将应用程序从EF4迁移到Dapper.net。我不确定可行性和Dapper中缺少此迁移任务的业务收益，因为EF4的以下功能缺失：
请在此建议我，或者如果WPF应用程序存在其他更好的微ORM。
答案 0 :(得分：3)
EF4和dapper是具有不同目标和不同功能的不同工具。事实上，看起来像EF这样的工具和工具并行工作（有时甚至是针对相同的对象模型）是很常见的 - 特别是当你没有使用所有你列出的东西时子弹;例如，许多“显示”代码（向用户显示页面等）往往不使用这些东西。对于只读代码，切换到一个精巧的实现有时会非常简单 - 只需编写一些SQL就可以了。
然而！当谈到 使用您提到的功能的代码时，这是一个更为根本的变化;它并不像“重新实施”那样真正“迁移”。如果没有变更跟踪等内容，您自己的代码需要更清楚地了解每个流程执行的操作。这实际上是一件好事，IMO，但改造成现有的代码库并不是一件容易的事。如果从 scratch （或现有模型中的新表等）开始，通常很容易。
就个人而言，我在这里采用的方法是首先来查看您的关键数据获取操作（特别是高频率，复杂查询或大量） - 并考虑是否可以用小巧的替换它们基于读取操作; 尤其是，如果只读。你可以用最少的工作获得一些巨大的胜利。分析很重要，像迷你分析器这样的工具可能会有所帮助。我会不亲自开始为其余部分剥离现有的工作数据层 - 这似乎是为了它而发明工作;并且它会很复杂（换掉ORM 不是一件微不足道的事情）。
然而， 会对更新到更新版本的EF进行认真考虑; p（哦，如果重要的话：我是小巧玲珑的主要作者和维护者）
答案 1 :(得分：0)
在我看来，关键问题是您的客户希望您将此项目迁移到另一个框架。
如果由于某些功能或模块的性能不佳而希望您执行此迁移，那么您可以采用Marc的方法并仅迁移系统的关键部分。
在我公司的一些项目中，我们将Dapper与完整的NHibernate东西并排使用，它确实有效。特别是在报表和批处理时，您可能希望调用存储过程而不是简单的CRUD操作。
如果您决定遵循这条道路，我建议您考虑使用＆＃34;工作单位＆＃34;模式以启用EF 和Dapper一起工作在同一个数据库连接上（我前段时间对此问题bloged）。
当然，你必须记住技术差异，比如Dapper（与＃34相反;完全成熟＆＃34;像EF或NH这样的ORM）没有会话概念和＆＃34;脏＆＃ 34;只有在刷新更改为DB后，才能由Dapper读取由EF修改的对象。