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

Question

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

Dapper似乎有助于通过SQL查询将对象映射到类。这对我来说还不够，因为我想将查询构建到服务之类的应用程序类中，然后在进入存储库（也称为Dapper）之前对它们进行单元测试。 我希望ORM可以将查询翻译成sql。精致的接缝不应以这种方式使用。因此，我想知道是否仍然需要在sql中构建所有业务逻辑有什么意义。

我的问题是，我是否需要像休眠一样的其他ORM？我想我正在寻找有关如何评估此工具的指导。

Answer 1

我的经验是，ORM框架具有一系列功能和复杂性，通常在速度和易用性方面存在反相关的折衷。

对于我来说，Dapper在功能和复杂性方面处于排在最后的位置，但要权衡一下它的速度非常出色。这并不是说Dapper并不复杂并且没有功能，只是说它没有会话，查询构建等功能，而在另一端您将在ORM中找到它，例如NHibernate。

如果您想要一个ORM将基于面向对象的域模型构建SQL查询，那么Dapper不适合您。您可以查看NHibernate，实体框架，LLBLGen和ORMLite（？）。 N.b.我希望还有其他我想念的。

Answer 2

您必须看看SQL Plus Dot Net。相反，它是实体框架，也就是说，实体框架从您的C＃代码构建SQL语句，而SQL + .net从您的SQL构建C＃代码。 这确实是很长时间以来数据访问领域的第一个真正的创新。