orm - 如果我不想在 sql 上编写查询，为什么要使用 Dapper

Question

我正在做的项目90%的业务逻辑都在存储过程中。我将 Dapper 视为将其中一些业务规则转移到应用程序层的可能途径。对我的好处是显而易见的，因为我可以进行单元测试等。

Dapper 似乎有助于通过 sql 查询将对象映射到类。这对我来说还不够，因为我想将查询构建到像服务这样的应用程序类中，然后在进入我的存储库(又名 Dapper)之前对它们进行单元测试。我希望 ORM 将我的查询转换为 sql。精致的接缝不适合以这种方式使用。所以我想知道如果我仍然必须在 sql 中构建所有业务逻辑还有什么意义。

我的问题是，我需要像 hibernate 这样的不同 ORM 吗？我想我正在寻找一些关于如何评估这个工具的指导。

Answer 1

我的经验是，ORM 框架存在一系列功能和复杂性，通常会在速度和易用性方面做出相反的妥协。

对我来说，Dapper 在功能和复杂性方面处于最末端，但代价是它的速度非常出色。这并不是说 Dapper 不复杂且功能较少，只是它没有 session 、查询构建等功能，而您可以在该范围另一端的 ORM 中找到这些功能，例如NHibernate。

如果您想要一个基于面向对象的域模型构建 SQL 查询的 ORM，那么 Dapper 不适合您。 NHibernate、Entity Framework、LLBLGen 和 ORMLite(？) 是您可以考虑的选项。注意:我希望还有其他我错过的。