几年来，我不得不支持一个使用 Fluent NHibernate 的项目，老实说，我已经厌倦了。我想继续使用 Dapper-dot-net (https://github.com/StackExchange/dapper-dot-net)，但我的一些团队反对使用它，因为担心将两个 ORM 框架混合到一个项目中。
他们的担忧是否合理？有没有人在这方面有经验，可以列出为什么 NHibernate 和 Dapper（或其他 ORM 框架）不能同时存在于同一个项目中？
谢谢，
【问题讨论】：
标签： .net fluent-nhibernate dapper
首先，我没有在同一个项目中结合 Fluent NHibernate (FNH) 和 Dapper 的直接经验，所以请记住这一点！但是我在单独的项目中独立使用了 FNH、Entity Framework 和 Dapper，并且选择 Dapper 作为最新项目正是因为它的简单性并且我想避免使用更重量级的 ORM，我个人可以看到 Dapper 对更多功能的吸引力丰富的替代品。虽然没有理由说明这两者不能存在于同一个项目中本身，但我认为您的团队完全有理由反对在同一个项目中引入另一种数据访问技术 /em>（但是这些担忧是否超过迁移到 Dapper 的优势当然取决于您团队的特定要求）。
立即想到的一些技术考虑/担忧：
在功能齐全的 ORM 和精简的 ORM 之间进行心理上下文切换 ADO.NET 的包装器。虽然在微不足道的情况下替换：
查询(a => a.Id == id && a.Active == true)...
与
“哪里 id = @Id AND active = true”...
不会是一个巨大的精神跳跃，我可以理解，在调试时，在一个使用 FNH 的查询与另一个使用原始 SQL 的查询之间切换，反之亦然，这对您的团队来说可能不是最愉快的体验尤其是对于更复杂的查询。
您是否计划像目前一样使用 Dapper 查询返回/使用相同的域实体集？如果是这样，如果您需要复制延迟加载（您当前可能正在使用，但 Dapper 中不会提供）和实体关系等功能，是否会出现问题？
Dapper 显然会要求您手写 SQL 查询。如果选择 FNH 是因为您的团队积极地更喜欢编写 LINQ 样式查询而不是原始 SQL，或者更重要的是因为他们不熟悉 SQL，那么引入 Dapper 也会迫使您的团队了解 SQL 的学习曲线。
Dapper 不会对您的查询提供编译时检查，因此您的团队可能会习惯和依赖的流畅映射和查询中通常会提取的对实体的任何更改都不会标记。
一个更普遍的问题是您计划如何长期处理这两者的结合。我不熟悉您的特定项目以及您使用了多少 FNH 功能，因此以下内容可能没有实际意义，但是如果您打算仅使用 dapper，则保留现有代码库，大概您需要保留拥有如果需要大量使用 FNH 功能的复杂查询需要大量重构或调试，则使用 FNH 的专业知识。
【讨论】：
澄清一下：我认为您要问的是在同一个项目中同时使用 nHibernate 和 Dapper。 （Fluent nHibernate 不是 ORM，它是一个帮助映射的库）。
多年来，我一直在使用 nHibernate + FNH，并且在我最近的两个 Web 项目中引入了 Dapper.net，因为我一直在寻找提高读取性能的方法。我的项目是使用 CQS 构建的，它允许我使用 nHibernate 进行写入（命令）和使用 Dapper.net 进行读取（查询）。这为我提供了 nHibernate 的强大功能和超快的阅读速度。
你的团队可能会遇到两个问题：
如果您只是因为厌倦了 nHibernate 而想要这样做，他们有充分的理由担心。
【讨论】：