我读过一篇名为Blogging with Noir的博客文章，我真的很惊讶作者使用java.jdbc而不是像Korma这样的库，这让我感到惊讶。在代码中编写SQL查询而不是让工具为您编写查询有什么好处？
我想是因为通常的原因，您可能会选择直接在Clojure中使用API，而不是使用包装器：
- 现有知识：您已经很了解JDBC，并且知道它会完成任务，为什么要花时间学习一个新的抽象，除非有明显的优势
- 不确定性-库是否具备您所需的所有功能？它将来会继续维护并实现新功能吗
- 稳定性-包装器可能还不成熟，因此如果发生破坏性更改/发现错误，您将面临代码必须更改的风险
- 完整性-包装器可能（尚未）封装您需要的原始API的所有功能
- 开销-有时额外的抽象层会增加您不需要/不想要的性能开销
- 额外的依赖性-增加了构建的复杂性，并在需要记住的抽象数量方面增加了概念开销
最终，这是一种权衡-以上是您可能想要使用底层API的原因，但也有同样好的理由您可以选择使用包装器：
- 更惯用-与基于Java的API相比，包装器库可能会为您提供更干净、更优雅的代码（特别是如果Java API是命令式/有状态的）。你必须承认，科尔玛非常优雅
- 更易于组合-Clojure包装器倾向于采用函数式风格，这使得与其他Clojure代码/库易于组合
- 新功能-Clojure包装器通常会添加原始API不具备的额外功能（例如，查看Seesaw在Swing之上添加的数据绑定功能）
Korma IMO还没有准备好作为SQL的完全替代品。它确实很方便，但现在我的很多查询中都有（原始的"…"）片段，对于更复杂的东西，所有的主要查询都是在SQL视图中完成的，然后通过korma进行选择。
主要的替代方案ClojureQL甚至不适用于Clojure 1.3+
简言之，抽象SQL很难，而Korma——尽管它试图最小化，这意味着你仍然必须很好地理解SQL才能使用它——还没有完成。
我可以考虑两个原因：
- 几乎所有人都知道SQL，几乎没有人知道Korma
- 这是一种猜测，因为我自己并不了解Korma，但如果你想做一些特定的事情，比如只存在于特定数据库中的功能，原始SQL有时是合适的，甚至是必要的