我读过一篇名为Blogging with Noir的博客文章,我真的很惊讶作者使用java.jdbc而不是像Korma这样的库,这让我感到惊讶。在你的代码中编写 SQL 查询而不是让工具为你做这件事有什么好处?
问问题
779 次
3 回答
9
我想这是出于通常的原因,您可能会选择直接在 Clojure 中使用 API 而不是使用包装器:
- 现有知识:您已经非常了解 JDBC,并且知道它可以完成工作,除非有明显的优势,否则为什么要花时间学习新的抽象?
- 不确定性- 库是否具有您需要的所有功能?将来会继续维护并实现新功能吗?
- 稳定性- 包装器可能尚未成熟,因此如果发生重大更改/发现错误,您将面临代码必须更改的风险。
- 完整性- 包装器可能(尚未)封装您需要的原始 API 的所有功能
- 开销- 有时额外的抽象层会增加您不需要/不想要的性能开销
- 额外的依赖- 增加了构建的复杂性,以及需要记住的抽象数量的概念开销。
归根结底,这是一种权衡——以上是您可能想要使用底层 API 的原因,但同样有充分的理由可以选择使用包装器:
- 更惯用- 包装库可能会为您提供比基于 Java 的 API 更清洁、更优雅的代码(特别是如果 Java API 是命令式/有状态的)。你不得不承认科尔马非常优雅!
- 更可组合- Clojure 包装器倾向于采用函数式风格,这导致与其他 clojure 代码/库的轻松组合。
- 新功能- Clojure 包装器通常会添加原始 API 不具备的额外功能(例如,查看 Seesaw 在 Swing 之上添加的数据绑定功能)
于 2012-09-06T08:33:07.337 回答
7
Korma IMO 还没有准备好完全替代 SQL。这绝对很方便,但现在我的很多查询都有(原始“...”)片段,对于更复杂的东西,所有主要查询都是在 SQL 视图中完成的,然后通过 korma 选择这些视图。
主要的替代品 ClojureQL 甚至不适用于 Clojure 1.3+
简而言之,很难抽象 SQL,而且 Korma——尽管它试图做到最小,这意味着你仍然必须很好地理解 SQL 才能使用它——还没有完成。
于 2012-09-06T08:29:05.093 回答
3
我可以想到两个原因:
- 几乎每个人都知道 SQL,几乎没有人知道 Korma
- 这是一个猜测,因为我自己并不了解 Korma,但如果您想做一些特定的事情,比如只存在于特定数据库中的功能,原始 SQL 有时是合适的,甚至是必要的
于 2012-09-06T08:27:59.003 回答