Database Clojure数据库交互-应用程序设计/方法

我希望这个问题不要太笼统或没有意义

我目前正在开发一个与SQLite数据库对话的基本应用程序，因此我自然会使用

clojure.java.jdbc

library（）与数据库进行交互

问题是，据我所知，使用此库将数据插入数据库的方法只是简单地传递一个映射（例如

{:id 1:name“stackoverflow”}

和一个表名（例如

:website

）

我关心的是如何在我的应用程序更广泛的上下文中使其更加健壮？我的意思是，当我将数据写入数据库并检索它时，我希望在应用程序中的任何地方都使用相同格式的映射，因此从数据访问层（返回或传递映射）开始一直到应用层，它处理数据并再次向下传递

我想了解的是，是否有一种类似于JavaBeans的“惯用”clojure

---

我现在面临的问题是，必须通过使用列名等手动定义映射来重复我自己的操作，但是如果我在数据库中更改表的结构，我的整个应用程序都必须更改。

据我所知，确实没有这样的库。有各种各样的系统可以使编写查询变得更容易，但无论如何都不方便“修复”您的数据对象

我一直在尝试写一些像你自己建议的东西，但我放弃了这个项目，因为很快就发现在clojure系统中这样做根本不是正确的（事实上，我现在倾向于认为，即使在真正“固定”数据结构的语言中，这种方法的使用也非常有限）

clojure收集系统的问题：

• 所有的地图访问/更改功能都非常实用 这意味着地图上的更改总是返回一个新对象，因此 几乎不可能创建一个强制固定的映射类型 在惯用clojure中易于使用

一般概念问题：

• 你的假设是你可以“在任何地方使用相同格式的地图” 在应用程序中，因此从数据访问层（返回或 传递地图）一直到应用程序层 处理数据并再次向下传递“如果 这个系统甚至有点复杂。你最多可以从 在一些简单的情况下，DB可以扩展到UI，但另一种方式是 几乎总是错误的方法

• 几乎每个查询都有自己的结果行“type”；您 可能无法在查询中重复使用这些“类型” 甚至在相关代码中

• 另外，在程序的其余部分强制使用这些类型可能是错误的 严格地将应用程序绑定到DB架构。如果 业务逻辑功能是健全的，写得很好，它们应该 尽可能多地访问他们需要的数据，而不是更多；他们可能应该这样做 不要到处使用相同的数据格式

---

我严肃的回答是：不用麻烦了。为您想要运行的查询类型编写您的DB访问函数，让这些函数检查进出DB的值，尽可能多地让您感到舒适。不要试图强制保持来自DB的数据“相同”在应用程序的其余部分。如果要在应用程序的其余部分检查数据格式，请使用断言和前置/后置条件。

Clojure支持

少量数据结构和大量函数的概念来处理这些少量数据结构。

。创建新数据结构的方法很少（我猜这在内部使用基本数据结构）类似于defrecord等，但如果您能够使用它们，这并不能真正解决数据库模式更改对代码的影响较小的问题，因为您最终必须通过层来删除/添加模式更改的影响，因为无论您在何处读取/创建需要更改的数据

Excellent回复，谢谢！所以建议保留特定于数据库层的特定于模式的内容，这应该对它接收到的任何数据进行任何转换？应用程序的其余部分应该避免耦合到数据库？