混合使用 Fluent NHibernate 和 Dapper-dot-net 有哪些潜在问题？
What are potential problems with mixing Fluent NHibernate and Dapper-dot-net?
几年来我不得不支持一个使用 Fluent NHibernate 的项目，老实说我已经厌倦了。我想继续使用 Dapper-dot-net (https://github.com/StackExchange/dapper-dot-net)，但由于担心将两个 ORM 框架混合到一个项目中，我的一些团队反对使用它。
他们的担心有道理吗？有没有人在这方面有经验可以列出为什么 NHibernate 和 Dapper（或其他 ORM 框架）不能在同一个项目中共存？
谢谢，
首先，我没有在同一个项目中结合 Fluent NHibernate (FNH) 和 Dapper 的直接经验，所以请记住这一点！然而，我在不同的项目中独立使用了 FNH、Entity Framework 和 Dapper，并且在最近的项目中选择 Dapper 正是因为它的简单性以及我想避免使用更重量级的 ORM，我个人可以看到 Dapper 的吸引力更多功能丰富的替代品。尽管没有理由不能将两者存在于同一个项目中 本身 ，但我认为您的团队完全有理由反对将另一种数据访问技术引入 [=32] =]相同的项目（但是，这些问题是否超过迁移到 Dapper 的优势当然取决于您团队的特定要求）。
一些直接的技术 considerations/concerns 会 spring 记住：
全功能 ORM 和精简 ORM 之间的心理上下文切换
ADO.NET 周围的包装器。虽然在微不足道的情况下替换：
查询(a => a.Id == id && a.Active == true)...
和
"WHERE id = @Id AND active = true"...
不会是一个巨大的心理跳跃，我可以理解，在调试时，在一个使用 FNH 的查询与另一个使用原始 SQL 的查询之间切换，反之亦然可能不会是为您的团队带来最愉快的体验，尤其是对于更复杂的查询。
您是否计划 returning/consuming 使用 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 的力量和超快的阅读速度。
您的团队在结合两者时可能遇到的问题：
- 项目架构不合适/难以更改
- 手动编写 sql 需要额外的工作
- 映射实体或创建和映射 DTO 需要额外的工作
- 引入它并没有真正的好处
如果你只是因为厌倦了 nHibernate 而想这样做，他们就有充分的理由担心。
几年来我不得不支持一个使用 Fluent NHibernate 的项目，老实说我已经厌倦了。我想继续使用 Dapper-dot-net (https://github.com/StackExchange/dapper-dot-net)，但由于担心将两个 ORM 框架混合到一个项目中，我的一些团队反对使用它。
他们的担心有道理吗？有没有人在这方面有经验可以列出为什么 NHibernate 和 Dapper（或其他 ORM 框架）不能在同一个项目中共存？
谢谢，
首先，我没有在同一个项目中结合 Fluent NHibernate (FNH) 和 Dapper 的直接经验，所以请记住这一点！然而，我在不同的项目中独立使用了 FNH、Entity Framework 和 Dapper，并且在最近的项目中选择 Dapper 正是因为它的简单性以及我想避免使用更重量级的 ORM，我个人可以看到 Dapper 的吸引力更多功能丰富的替代品。尽管没有理由不能将两者存在于同一个项目中 本身 ，但我认为您的团队完全有理由反对将另一种数据访问技术引入 [=32] =]相同的项目（但是，这些问题是否超过迁移到 Dapper 的优势当然取决于您团队的特定要求）。
一些直接的技术 considerations/concerns 会 spring 记住：
全功能 ORM 和精简 ORM 之间的心理上下文切换 ADO.NET 周围的包装器。虽然在微不足道的情况下替换：
查询(a => a.Id == id && a.Active == true)...
和
"WHERE id = @Id AND active = true"...
不会是一个巨大的心理跳跃，我可以理解，在调试时，在一个使用 FNH 的查询与另一个使用原始 SQL 的查询之间切换，反之亦然可能不会是为您的团队带来最愉快的体验，尤其是对于更复杂的查询。
您是否计划 returning/consuming 使用 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 的力量和超快的阅读速度。
您的团队在结合两者时可能遇到的问题：
- 项目架构不合适/难以更改
- 手动编写 sql 需要额外的工作
- 映射实体或创建和映射 DTO 需要额外的工作
- 引入它并没有真正的好处
如果你只是因为厌倦了 nHibernate 而想这样做，他们就有充分的理由担心。