为什么有人想使用JDBC而不是像korma这样的库？

Question

我已经阅读了一篇名为Blogging with Noir的博文，我真的很惊讶作者使用java.jdbc代替Korma这样的库，我觉得这很令人惊讶。在代码中编写SQL查询而不是让工具为您执行此操作有什么好处？

Answer 1

我想通常的原因是你可以选择直接在Clojure中使用API​​而不是使用包装器：

• 现有知识：您已经很好地了解了JDBC，并且知道它将完成工作，为什么要花时间学习新的抽象，除非有明显的优势？
• 不确定性 - 图书馆是否具备您需要的所有功能？将来是否会继续维护并实施新功能？
• 稳定性 - 包装器可能尚未成熟，因此如果发生重大更改/发现错误，您将面临更改代码的风险。
• 完整性 - 包装器可能（尚未）封装了您需要的原始API的所有功能
• 开销 - 有时额外的抽象层会增加您不需要/不想要的性能开销
• 额外依赖 - 增加了构建的复杂性，以及您需要保留在脑中的抽象数量的概念开销。

最终这是一个权衡 - 以上是您可能想要使用底层API的原因，但是您可以选择使用包装器的理由相同：

• 更具惯用力 - 与基于Java的API相比，封装库可能会为您提供更清晰，更优雅的代码（特别是在Java API是命令性/有状态的情况下）。你必须承认Korma非常优雅！
• 更具可组合性 - Clojure包装器倾向于采用功能样式，这样可以轻松与其他clojure代码/库进行组合。
• 新功能 - 通常Clojure包装器会添加原始API不具备的额外功能（例如，查看由Swes by Seesaw添加的数据绑定功能）

Answer 2

Korma IMO几乎没有准备好用作SQL的完全替代品。它绝对方便，但是现在很多我的查询都有（原始的“......”）片段，而对于更复杂的东西，所有的主要查询都是在SQL视图中完成的，然后通过korma选择。

主要替代方案ClojureQL甚至不适用于Clojure 1.3 +

简而言之，它是 hard 抽象SQL和Korma - 即使它试图最小化，这意味着你仍然必须很好地理解SQL才能使用它 - 还没有完成。

Answer 3

我可以考虑两个原因：

1. 几乎每个人都知道SQL，几乎没有人知道Korma
2. 这是一个猜测，因为我自己并不了解Korma，但如果你想做一些像特定数据库中只存在的功能这样的特定事情，原始SQL有时是合适的，甚至是必要的