我希望这个问题不是太笼统或没有意义。
我目前正在开发一个与SQLite数据库对话的基本应用程序,所以我自然而然地使用clojure.java.jdbc
库(link)与数据库进行交互。
据我所知,麻烦的是,使用这个库将数据插入数据库的方法是简单地传递一个地图(例如{:id 1 :name "stackoverflow"}
和一个表名(例如:website
)
我关注的是如何在更广泛的应用环境中使其更加强大?我的意思是当我将数据写入数据库并检索它时,我想在应用程序中使用相同的格式化地图,所以从数据访问层(返回或传入地图)一直到应用程序它处理数据的图层,然后再将其传回。
我想要了解的是,是否存在与JavaBeans相当的'惯用'clojure?
我现在遇到的问题是必须通过使用列名等手动定义地图来重复自己 - 但如果我在数据库中更改了我的表的结构,则必须更改整个应用程序。
答案 0 :(得分:4)
据我所知,确实没有这样的图书馆。有各种系统可以更容易地编写查询,但不是AFAIK,任何“修复”数据对象的东西。
我一直在试图写一些像你自己提出的建议,但是我放弃了这个项目,因为它很快变得非常明显,这在clojure系统中根本不是正确的事情(事实上,我倾向于现在想一想,即使在具有真正“固定”数据结构的语言中,该方法的使用也非常有限。)
clojure收集系统的问题:
一般概念问题:
您假设您可以“在任何地方使用相同的格式化地图 在应用程序中,所以从数据访问层(返回或 传递映射)一直到应用层所在的位置 处理数据并再次将其传回“是错误的,如果你的 系统甚至有点复杂。在最佳,您可以使用地图 在一些简单的情况下,数据库直到UI,但另一种方式是 几乎总是错误的做法。
几乎每个查询都有自己的结果行“type”;你是 可能无法跨查询重用这些“类型” 甚至在相关的代码中。
此外,可能会在程序的其余部分强制使用这些类型 将您的应用程序更多严格绑定到数据库架构。如果你的 业务逻辑功能是理智的,写得很好,它们应该只有 访问尽可能多的数据,而不是更多;他们可能应该 不要在任何地方使用相同的数据格式。
我认真的回答是;不要打扰。为您想要运行的查询类型编写数据库访问函数,并让这些函数检查进出DB的值,尽可能详细。不要试图在应用程序的其余部分强制保持来自数据库的数据“相同”。如果要在应用程序的其余部分检查数据格式,请使用断言和前/后条件。
答案 1 :(得分:2)
Clojure赞成Few data structure and lots of functions to work on these few data structures
的概念。有很多方法可以创建新的数据结构(我猜在内部使用基本的数据结构),如defrecord等。但是,如果你能够使用它们并不能真正解决数据库模式更改应该影响的问题代码少,因为您最终必须通过图层来删除/添加架构更改的效果,因为您正在阅读/创建需要更改的数据的任何地方