Взаимодействие с базой данных Clojure - дизайн приложения / подход

Question

Надеюсь, этот вопрос не слишком общий или не имеет смысла.

В настоящее время я разрабатываю базовое приложение, которое взаимодействует с базой данных SQLite, поэтому, естественно, я использую библиотеку clojure.java.jdbc ( link ) для взаимодействия с БД.

Проблема, насколько я могу судить, заключается в том, что вы вставляете данные в БД с помощью этой библиотеки, просто передавая карту (например, {:id 1 :name "stackoverflow"} и имя таблицы (например, :website)

Что меня беспокоит, так это то, как я могу сделать это более устойчивым в более широком контексте моего приложения? Под этим я подразумеваю, что когда я записываю данные в базу данных и извлекаю их, я хочу использовать одну и ту же отформатированную карту ВСЕГДА в приложении, то есть со слоя доступа к данным (возвращая или передавая карты), вплоть до приложения. слой, где он работает с данными и снова передает их обратно.

Я пытаюсь понять, существует ли «идиоматический» эквивалент clojure JavaBeans?

Проблема, с которой я сейчас сталкиваюсь, заключается в том, чтобы повторяться, определяя карты вручную с именами столбцов и т. Д., Но если я изменяю структуру моей таблицы в БД, все мое приложение должно быть изменено.

Answer 1

Насколько я знаю, там действительно нет такой библиотеки. Существуют различные системы, которые облегчают написание запросов, но не AFAIK, все, что «исправляет» ваши объекты данных.

Я безуспешно пытался написать что-то вроде того, что вы предлагаете себе, но я отказался от проекта, так как очень быстро стало очевидно, что это совсем не то, что нужно делать в закрытой системе (и на самом деле, я склонен теперь подумайте, что этот подход имеет очень ограниченное применение даже в тех языках, которые действительно «фиксировали» структуры данных).

Проблемы с системой сбора clojure:

• Все функции доступа / изменения карты действительно функциональны. Тот означает, что изменения на карте всегда возвращают новый объект, поэтому почти невозможно создать принудительно фиксированный тип карты, который также прост в использовании в идиоматическом замыкании.

Общие концептуальные вопросы:

• Ваше предположение, что вы можете "использовать одну и ту же отформатированную карту ВЕЗДЕ в приложении, так от уровня доступа к данным (возвращая или переходя в карты) вплоть до уровня приложения, где он работает с данными и передает их обратно " неправильно, если ваш Система даже немного сложна. На лучше , вы можете использовать карту из БД до пользовательского интерфейса в некоторых простых случаях, но наоборот почти всегда неправильный подход.

• Почти каждый запрос будет иметь свою собственную строку результата "тип"; Вы вероятно не сможет повторно использовать эти "типы" в запросах даже в связанном коде.

• Кроме того, форсирование этих типов в остальной части программы, вероятно, привязка вашего приложения more строго к схеме БД. Если твой функции бизнес-логики вменяемые и хорошо написанные, они должны только получить доступ к как можно большему количеству данных и не более; они должны вероятно не везде использовать один и тот же формат данных.

Мой серьезный ответ: не беспокойся Напишите свои функции доступа к БД для тех типов запросов, которые вы хотите выполнить, и позвольте этим функциям проверять значения, входящие и выходящие из БД, настолько подробно, насколько вам удобно. Не пытайтесь принудительно сохранять данные, поступающие из БД, «одинаковыми» в остальной части вашего приложения. Используйте утверждения и предварительные / последующие условия, если вы хотите проверить формат данных в остальной части приложения.

Answer 2

Clojure поддерживает концепцию Few data structure and lots of functions to work on these few data structures. Есть несколько способов создать новую структуру данных (которая, я думаю, внутренне использует базовые структуры данных), например, defrecord и т. Д. Но опять же, если вы можете использовать их, это не решит проблему, которая должна повлиять на изменения схемы БД . код меньше , так как вам в конечном итоге придется пройти через слои, чтобы удалить / добавить эффекты изменений схемы, потому что везде, где вы читаете / создаете те данные, которые нужно изменить