Esta es mi opinión:
- JPA: forma Agnóstico hacer la persistencia de Java sin acoplamiento a sus clientes a Hibernate, TopLink, etc.
- Hibernate: Una buena opción si usted tiene un modelo de objetos para asignar a.
- JDBC: Toda la persistencia de Java se basa en esto. Nivel más bajo
- DAO: Más de un patrón que una tecnología; Interfaz de operación CRUD.
- iBatis: A medio camino entre JDBC (SQL sin formato) e Hibernate (ORM).
- JDO: Java Data Objects, que es otra especificación para la persistencia de Java. (p.ej., Apache JDO)
No es una aplicación compleja. Contiene sólo 5 mesas (y 5) entidades
Cualquiera de estos funcionará, pero JDBC será el más simple. Todos los demás están construidos sobre JDBC.
Quiero hacer mi código flexible, de modo que puedo cambiar la base de datos más adelante fácilmente
Los cambios de esquema tendrá efectos similares en todas las tecnologías.
El tamaño de la aplicación debe mantenerse lo más pequeña posible como yo quiero que distribuir a mis clientes a través de internet.
El uso de JPA o Hibernate requerirá JAR que se sumarán al tamaño de su implementación. JDBC minimizará esto.
Debe ser libre de usar en el desarrollo y la distribución comercial.
Consulte las licencias de todas las tecnologías. No debería ser un problema con ninguno de ellos.
FYI: Es posible escribir una interfaz DAO genérico:
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);
}
Si los objetos en el mapa 1: 1 con sus cinco mesas, yo diría que es un exceso APP cuadrado.
¿Su aplicación actualmente es del orden de 3MB JAR? Si no, entonces Hibernate o JPA duplicarán el tamaño. Puede cuantificar exactamente cuánto. Y hay más de un JAR, porque ambos tienen dependencias.
YAGNI dice que debes mantenerlo simple. ¡Son cinco mesas!
Cambiar de proveedor, si lo hace correctamente, significa cambiar un JAR de controlador JDBC, cambiar el nombre de la clase de controlador y agregar la nueva URL de conexión, lo cual tiene que hacer sin importar qué tecnología elija.
Encuentro que las bases de datos no cambian tan radicalmente. ¿Cambiará el esquema, pero todo el proveedor? No es probable, especialmente si tiene varios clientes. Sería un gran inconveniente hacer que una base de datos de usuario cambie de base de datos.
¿Con cuál planeabas viajar? HSQL o algo que requerirá una instalación como MySQL? Esa es una preocupación más pertinente.
Puede que le interese esta pregunta previa mía: "Hibernate vs JPA vs JDO - pros y contras de cada uno?" http://stackoverflow.com/questions/530215/hibernate-vs-jpa-vs-jdo-pros-and-cons-of-each –
También verifique http://stackoverflow.com/questions/2397016/java-jdbc- alternativas/ –