Java - слой или плагин DAO

Question

Я работаю над проектом JBJF на SourceForge, и мы хотим улучшить доступ к базам данных для этой платформы. В настоящее время он полужесткий, но доступ осуществляется на уровне задач.

Мы хотели бы установить простой интерфейс некоторого вида, который является универсальным по своей природе и может размещать доступ к базе данных в / из JBJF. Таким образом, классы Framework не заботятся о том, какая база данных, они просто вызывают метод, такой как getConnection (), и возвращается объект java.sql.Connection.

Мне интересно, что подойдет лучше: типичный слой DAO с одним интерфейсом или структура типа плагинов, где мы конфигурируем службу базы данных в XML-файле, а платформа загружает плагин (ы) при его запуске.

ТИА,

adym

Answer 1

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

Answer 2

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

Например, напишите WidgetRepository интерфейс, который определяет часть виджета вашего API доступа к данным. Затем вы можете предоставить FileSystemWidgetRepository , HibernateWidgetRepository , XmlWidgetRepository , JpaWidgetRepository и т. Д., Реализующий ваш интерфейс.

Общее правило заключается в том, чтобы использовать как можно более высокий уровень абстракции при выполнении ваших требований. В приведенном мною списке примеров репозиторий на основе JPA будет наивысшим уровнем, поскольку он абстрагирует даже среду ORM.

Затем вы можете сохранить ссылку WidgetRepository в ваших объектах, которые ее используют. Код только против этого интерфейса. Затем создайте Dependency Injection фреймворк, подобный Spring , который будет внедрять конкретную реализацию WidgetRepository во время выполнения на основе некоторой конфигурации XML или механизма автоматического подключения.

Answer 3

как насчет абстрагирования от всего этого и использования JPA

Answer 4

Я начинал думать, что Hibernate стал слишком большим и раздутым, но я недавно работал над проектом с использованием последней версии 3.5 и с использованием JPA, и они определенно уменьшили его и сделали его намного лучше, чем некоторые из другие релизы 3.x. Я бы порекомендовал JPA, используя Hibernate: -)

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