我已经使用Fluent NHibernate支持了一个项目几年了，我老老实实已经厌倦了。我想继续使用Dapper-dot-net（https://github.com/StackExchange/dapper-dot-net），但由于担心将两个ORM框架混合到一个项目中，我的一些团队反对使用它。
他们的担忧是否合理？有没有人在这方面有经验可以列出为什么NHibernate和Dapper（或其他ORM框架）不能在同一个项目中一起存在？
谢谢，
答案 0 :(得分：3)
首先，我没有将Fluent NHibernate（FNH）和Dapper结合在同一个项目中的直接经验，所以请记住这一点！但是我在单独的项目中独立使用了FNH，实体框架和Dapper，并且选择Dapper作为最新项目正是因为它的简单性以及我想避免更重量级的ORM，我个人可以看到Dapper对更多功能的吸引力丰富的选择。虽然没有理由认为两者不能存在于同一个项目本身中，但我认为您的团队完全有理由提出将另一种数据访问技术引入同一项目的异议< / em>（但是，这些问题是否超过了转移到Dapper的优势当然取决于您团队的特殊要求）。
一些即时的技术考虑因素/担忧会浮现在脑海中：
全功能ORM和瘦身之间的心理上下文切换 围绕ADO.NET包装。虽然在琐碎的情况下取代：
查询（a =＆gt; a.Id == id＆amp;＆amp; a.Active == true）...
与
“WHERE id = @Id AND active = true”...
不会是一个巨大的心理跳跃，我可以理解，在调试时，在使用FNH的一个查询与使用原始SQL的另一个查询之间切换，反之亦然可能不会是您团队中最愉快的体验特别是对于更复杂的查询。
您是否计划使用目前的Dapper查询返回/使用同一组域实体？如果是这样，如果你需要复制延迟加载（你当前可能正在使用但不会在Dapper中提供）和实体关系等功能，是否会出现问题？
Dapper显然会要求您手写SQL查询。如果选择FNH是因为您的团队主动优先在原始SQL上编写LINQ样式查询，或者更重要的是因为他们不熟悉SQL，那么引入Dapper也会迫使您的团队学习SQL的学习曲线。 / p>
Dapper将不会对您的查询进行编译时检查，因此您的实体通常会在流畅的映射和查询中获取的任何更改（您的团队可能会对此感到满意并依赖）将不会标记。
更普遍的担忧是你计划如何在长期内处理两者的结合。我不熟悉您的特定项目以及您使用了多少FNH功能，因此以下内容可能没有实际意义，但是如果您计划仅使用dapper，请将现有代码库保留原样，大概您需要保留一个人如果需要大量重构或调试大量使用FNH功能的复杂查询，则使用FNH的专业知识。
答案 1 :(得分：0)
只是为了澄清：我认为你要问的是在同一个项目中使用nHibernate和Dapper。 （流利的nHibernate不是ORM，它是一个帮助映射的库。）
我多年来一直在使用nHibernate + FNH，在我的最后两个网站项目中介绍了Dapper.net，因为我一直在寻找读取性能改进。我的项目是使用CQS构建的，它允许我使用nHibernate进行写入（命令），使用Dapper.net进行读取（查询）。这给了我nHibernate的强大功能和快速阅读的一面。
您的团队在梳理两者时可能遇到的问题：
如果你只是因为厌倦了nHibernate而想要这样做，他们就有充分的理由担心。