Вопрос

Чтобы реализовать код доступа к данным в нашем приложении, нам нужна некая среда для jdbc (ORM — не наш выбор из-за масштабируемости).

Самый крутой фреймворк, с которым я когда-либо работал, — это Весна-Jdbc.Однако политика моей компании заключается в том, чтобы избегать внешних зависимостей, особенно Spring, J2EE и т. д.Итак, мы подумываем о написании собственного удобного jdbc-фреймворка с функциональностью, аналогичной Spring-jdbc:сопоставление строк, обработка ошибок, поддержка функций Java5, но без поддержки транзакций.

Есть ли у кого-нибудь опыт написания такой оболочки jdbc?Если у кого-то есть опыт использования других фреймворков-оболочек jdbc, поделитесь своим опытом.

Заранее спасибо.

Это было полезно?

Решение

Мы написали собственную обертку.Эта тема достойна статьи, но я сомневаюсь, что у меня когда-нибудь будет время ее написать, поэтому вот несколько ключевых моментов:

  • мы приняли sql и не пытались его скрыть.единственной поправкой было добавление поддержки именованных параметров.параметры важны, поскольку мы не рекомендуем использовать sql «на лету» (по соображениям безопасности) и всегда используем ReadedStatements.

  • для управления соединениями мы использовали Apache DBCP.В то время это было удобно, но неясно, насколько это необходимо для современных реализаций JDBC (документация по этому вопросу отсутствует).DBCP также объединяет подготовленные выражения.

  • мы не заморачивались с сопоставлением строк.вместо этого (для запросов) мы использовали что-то похожее на ResultSetHandler Apache dbutil, которое позволяет вам «подавать» набор результатов в метод, который затем может сбрасывать информацию туда, куда вам нужно.Это более гибко, и на самом деле не составит труда реализовать ResultSetHandler для сопоставления строк.для вставок/обновлений мы создали общий класс записей (по сути, хэш-карту с некоторыми дополнительными прибамбасами).самая большая проблема с сопоставлением строк (для нас) заключается в том, что вы застреваете, как только выполняете «интересный» запрос, потому что у вас могут быть поля, которые сопоставляются с разными классами;потому что у вас может быть иерархическая структура классов, но плоский набор результатов;или потому, что сопоставление сложное и зависит от данных.

  • мы встроили регистрацию ошибок.для обработки исключений:при запросе мы перехватываем и регистрируем, но при обновлении мы перехватываем, регистрируем и повторно выбрасываем непроверенные исключения.

  • мы обеспечили поддержку транзакций, используя подход-оболочку.вызывающая сторона предоставляет код, выполняющий транзакцию, и мы следим за тем, чтобы транзакция управлялась должным образом, без шансов забыть завершить транзакцию и со встроенными функциями отката и обработки ошибок.

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

На сегодняшний день эта оболочка успешно использовалась в двух проектах.Он, конечно, легкий, но сейчас все говорят, что их код легкий.Что еще более важно, это повышает производительность программистов, уменьшает количество ошибок (и облегчает отслеживание проблем), а также относительно легко их отследить, если это необходимо, потому что мы не верим в добавление большого количества слоев только для создания красивой архитектуры.

Другие советы

Spring-JDBC - это фантастика. Учтите, что для проекта с открытым исходным кодом, такого как Spring, отрицательная сторона внешней зависимости сведена к минимуму. Вы можете принять наиболее стабильную версию Spring, которая удовлетворяет вашим требованиям к абстракции JDBC, и вы знаете, что вы всегда сможете изменить исходный код самостоятельно, если у вас возникнут какие-либо проблемы - без зависимости от внешней стороны. Вы также можете проверить реализацию на предмет любых проблем безопасности, которые могут возникнуть в вашей организации с кодом, написанным внешней стороной.

Я предпочитаю: Дейлсбред . Это MIT по лицензии.

Простой пример получения всех строк для пользовательского класса (Department).

List<Department> departments = db.findAll(Department.class,
    "select id, name from department");

когда пользовательский класс определен как:

public final class Department {
    private final int id;
    private final String name;

    public Department(int id, String name) {
        this.id = id;
        this.name = name;
    }
}

Отказ от ответственности: это компания, в которой я работаю.

Это звучит как очень близорукое решение. Рассмотрите стоимость разработки / поддержки такой инфраструктуры, особенно когда вы можете ее получить, и ее исходный код предоставляется бесплатно. Мало того, что вам не нужно заниматься разработкой самостоятельно, вы можете изменить ее по желанию, если это будет необходимо.

Тем не менее, вам действительно нужно продублировать понятие JdbcTemplate и его обратных вызовов (PreparedStatementCreator, PreparedStatementCallback), а также RowMapper / RowCallbackHandler. Не должно быть слишком сложно написать что-то подобное (особенно если учесть, что вам не нужно управлять транзакциями).

Однако, как я уже сказал, зачем писать, если вы можете получить его бесплатно и изменить исходный код по своему усмотрению?

Попробуйте JdbcSession из jcabi-jdbc . Это так просто, как должно быть в JDBC, например:

String name = new JdbcSession(source)
  .sql("SELECT name FROM foo WHERE id = ?")
  .set(123)
  .select(new SingleOutcome<String>(String.class));

Вот и все.

mJDBC: https://mjdbc.github.io/

Я использую его годами и считаю его очень полезным.

Она основана на библиотеке JDBI, но не имеет зависимостей, добавляет поддержку транзакций, предоставляет счетчики производительности и позволяет легко переключаться на самый низкий возможный уровень SQL в Java (старый простой JDBC API), если вам это действительно нужно.

Лицензировано под: CC-BY-SA с атрибуция
Не связан с StackOverflow
scroll top