Быть в спящем режиме или JPA или JDBC или? [закрытый]

В этом масштабе все будет работать нормально. Рассмотрим также iBatis .

Вот мое мнение:

• JPA: Агностический способ сделать персистентность Java без привязки ваших клиентов к Hibernate, TopLink и т.д.
• Hibernate: Хороший выбор, если у вас есть объектная модель для отображения.
• JDBC: Вся персистентность Java построена на этом. Самый низкий уровень
• DAO: скорее паттерн, чем технология; интерфейс CRUD-операций.
• iBatis: На полпути между JDBC (необработанный SQL) и Hibernate (ORM).
• JDO: Java Data Objects, которая является другой спецификацией для персистентности Java. (например, Apache JDO)

Это не сложное приложение. Оно содержит только 5 таблиц (и 5 сущностей)

Любой из них будет работать, но JDBC будет самым простым. Все остальные построены поверх JDBC.

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

Изменения схемы будут иметь схожие эффекты во всех технологиях.

Размер приложения должен оставаться как можно меньше, так как мне придется придется распространять его среди моих клиентов через интернет.

Использование JPA или Hibernate потребует JARs, которые увеличат размер вашего развертывания. JDBC позволит свести это к минимуму.

Он должен быть свободен для использования в коммерческой разработке и распространении.

См. лицензии всех технологий. Ни с одной из них не должно быть проблем.

К вашему сведению: можно написать общий интерфейс DAO:

package persistence;

import java.io.Serializable;
import java.util.List;

public interface GenericDao<T, K extends Serializable>
{
    T find(K id);
    List<T> find();
    List<T> find(T example);
    List<T> find(String queryName, String [] paramNames, Object [] bindValues);

    K save(T instance);
    void update(T instance);
    void delete(T instance);
}

Если ваши объекты отображаются 1:1 с вашими пятью таблицами, я бы сказал, что JPA - это перебор в квадрате.

Ваше приложение в настоящее время имеет JAR размером порядка 3MB? Если нет, то Hibernate или JPA увеличат размер более чем в два раза. Вы можете точно определить, насколько. И это не один JAR, потому что у них обоих есть зависимости.

YAGNI говорит, что нужно быть проще. Это пять таблиц!

Смена поставщика, если вы сделаете это правильно, означает смену JDBC-драйвера JAR, изменение имени класса драйвера и добавление нового URL подключения - что вы должны сделать независимо от того, какую технологию вы выбрали.

Я считаю, что базы данных не меняются так радикально. Вы измените схему, но всего производителя? Вряд ли, особенно если у вас несколько клиентов. Будет большим неудобством заставить базу пользователей поменять базу данных.

С какой из них вы планировали поставлять? HSQL или что-то, что потребует установки, как MySQL? Это более актуальный вопрос.

JPA, безусловно, является тем способом, которым следует идти, если вы хотите использовать отображение объектных отношений - он не зависит от реализации (то есть вы можете использовать его с Hibernate, Toplink и т.д.) и является стандартом де-факто. Hibernate имеет более богатый набор функций, но это нестандартное решение - многие люди используют его... Лично я всегда использую JPA с поддержкой Hibernate. Я стараюсь держаться подальше от специфичных для Hibernate вещей, но если это необходимо - они там для меня.

Использование такого фреймворка, как JPA/Hibernate для 5 таблиц может быть немного излишним. Ваше приложение будет примерно на 5 Мб больше и будет потреблять больше памяти. Вы можете просто использовать JDBC в паре с DAO.

Поскольку JDBC использует SQL, который зависит от производителя (базы данных), это может быть проблематично, если вы планируете использовать различные базы данных. JPA имеет явное преимущество в этой области.

Что бы вы ни выбрали, вы не можете ошибиться - вы должны спросить себя, является ли увеличение размера и потребления памяти проблемой, и готовы ли вы писать код DAO JDBC. Я вообще ненавижу это :-)