sql - Micro ORM - 维护你的 SQL 查询字符串

Question

我不会详细说明我在这个阶段为什么要探索使用 Micro ORM——只是说当我使用完整的 ORM 时我感到无能为力。有太多的事情在后台自动发生，并不是所有的事情都是最好的选择。我已经准备好回到原始数据库访问，但我发现了三个新人:Dapper、PetaPoco 和 Massive。所以我决定在一个宠物项目中尝试一下低层次的方法。这无关紧要，但到目前为止，我正在使用 PetaPoco。

在任何情况下，我都无法决定如何维护我将从更高级别使用的 SQL 字符串。我能想到的主要解决方案有以下三种:

将 SQL 查询洒在我需要的地方。这是最不重基础设施的方法。但是，它在可维护性和可测试性方面都受到影响。

将查询使用限制为某些服务类。这有助于可维护性，我需要实现的基础设施仍然很低。也可以构建这些服务类，以便为测试目的轻松模拟。

准备一些类以使系统具有一定的灵 active 。我已经开始走这条路了。我实现了一个 Repository 接口(interface)和一个依赖于数据库的 Repository 类。我还构建了一些小接口(interface)来捕获可以传递给我的存储库的 GetMany() 方法的 SQL 查询。现在所有的查询都作为单独的类实现，我可能需要更多的接口(interface)来增加数据库的独立性——也许在将查询装饰成分页和排序查询时有一些灵 active (同样，这也会使它们在处理不同的数据库时更加灵活)。

我现在主要担心的是，我已经进入了编写完整 ORM 所需的所有功能的滑坡，但是很糟糕。例如，我现在感觉很明智，我编写或找到一个库来将 linq 调用转换为 SQL 语句，这样我就可以轻松地处理我的查询，或者编写可以装饰我传递给它的任何查询的扩展程序，等等。但这是一个很大的问题任务，而且已经被大佬们完成了，所以我忍住了要去那里的冲动。我还想保留对我发送到数据库的查询的控制——通过显式编写它们。

那么建议是什么？我应该选择＃2选项，还是尝试偶然发现选项＃3？我敢肯定，我不能不脸红地向任何人展示第一个选项中编写的任何代码。您还有其他方法可以推荐吗？

编辑:在我问完这个问题之后，我意识到还有另一个选项，与这三个选项有些正交:存储过程。将所有查询作为存储过程放入数据库中似乎有一些优点。它们被保存在一个中心位置，而不是通过代码传播(尽管维护是一个问题 - 参数可能会不同步)。对数据库方言的依赖是自动解决的:如果你移动数据库，你移植所有的存储过程，你就完成了。还有安全方面的好处。

使用存储过程选项，备选方案 1 和 2 似乎更合适一些。似乎没有足够的实体来保证选项 3 - 但仍然可以将过程调用命令与数据库访问代码分开。

我已经实现了没有存储过程的选项 3，以及带有存储过程的选项 2，似乎后者更适合我(如果有人对问题的结果感兴趣)。

Answer 1

I would say put the sql where you would have put the equivalent LINQ query, or the sql for DataContext.ExecuteQuery. As for where that is... well, that is up to you and depends on how much separation you want. - Marc Gravell, creator on Dapper

See Marc's opinion on the matter

我认为关键是，你不应该真的重用 SQL。如果您的逻辑被重用，那么它应该被包装在一个可以从多个地方调用的方法中。