java - entre - jpa vs jdbc

Java JDBC contra JPA para la aplicación de base de datos

Question

Me gustaría adelantar que soy un novato en busca de consejos ya que estoy tratando de construir buenos hábitos.

La aplicación que estoy desarrollando en este momento es una aplicación de base de datos muy integrada. A medida que desarrollo, exploro e implemento los requisitos para cada una de mis entidades, descubro que mis clases están explotando con código para ejecutar consultas de diferentes maneras en cada una de las entidades.

Si bien puede que no sea algo malo en este momento, en términos de mantenimiento, preveo que mi aplicación será una pesadilla para depurar y actualizar.

¿Algún experto en JDBC tiene alguna sugerencia de patrones de diseño que ayuden a adelgazar el código del tipo de placa de caldera para manejar todas estas consultas? ¿O debería desviarme completamente de eso y usar JPA?

Intenté implementar JPA en el pasado, pero he tenido problemas con relaciones de entidades complejas. ¿Debería leer un libro de JPA e ir desde allí?

Answer 1

Independientemente de la solución que utilice, ya sea directamente JDBC o JPA, asegúrese de dividir su código en partes que puedan intercambiarse fácilmente cuando llegue el momento de cambiar las tecnologías.

La desventaja de JDBC es que puede terminar con un código específico de implementación (Oracle, MS, MySQL, etc.). Esto puede ser un verdadero dolor para migrar si decide cambiar las cosas más adelante.

Terminé estudiando Hibernate, y el libro Harnessing Hibernate me ayudó a hacer ese tipo de desarrollo (y también trajo a Spring y Maven para el paseo, de una forma que lentamente se construyó una encima de la otra).

Con lo que debe terminar, independientemente de su enfoque, son:

• Objetos DAO: estos objetos de acceso a datos realizarán sus operaciones CRUD (crear, actualizar y eliminar) y deben ser independientes de la base de datos.

• Objetos de modelo: estos deberían representar sus datos, y probablemente se parecerán mucho a las representaciones de Java de una sola fila en una tabla de base de datos. Las clases de DAO devolverán estos, o listas de estos.

Aprovechar Hibernate describe un patrón en capítulos posteriores (después de que le haya lanzado a Spring) donde utilizará básicamente dos capas de clases DAO. La clase DAO de nivel más alto instanciará (o permitirá que se inyecte) una clase DAO específica de la implementación.

Entonces, imaginemos que tiene una tabla de base de datos de EMPLEADOS. Entonces crea un objeto modelo llamado Employee que contiene todos los datos que contiene una fila en la tabla EMPLOYEE. Ahora crea una clase DAO llamada EmployeeDAO que implementa lo siguiente:

EmployeeDAO.createEmployee(Employee emp)
EmployeeDAO.updateEmployee(Employee emp)
EmployeeDAO.deleteEmployee(Employee emp)

Su pensamiento inicial sería poner allí sus llamadas JDBC. Pero no lo hagas En cambio, ahora escribe otro DAO para Employee, y este implementará todas sus llamadas JDBC. (Suponiendo que vayas JDBC):

EmployeeJdbcDAO.create(Employee emp)
EmployeeJdbcDAO.update(Employee emp)
EmployeeJdbcDAO.delete(Employee emp)

Ahora los métodos en EmployeeDAO? Simplemente crean una instancia de EmployeeJdbcDAO y llaman al método apropiado. Cuando llega el momento de cambiar a Oracle con Hibernate, crea una nueva clase DAO llamada algo así como EmployeeOrHibDAO, escribe Hibernate y el código específico de Oracle allí, y luego en lugar de llamar a EmployeeJdbcDAO en EmployeeDAO, crea una instancia de EmployeeOrHibDAO en su lugar. (Y con Spring, ni siquiera cambias el código. Solo cambias tu configuración de Spring DI.)

Answer 2

No es una respuesta real , pero creo que es importante incluir un par de opciones más en la mezcla que pueden ayudarlo a encontrar un buen término medio. Sugiero esto porque una implementación de JPA en una base de datos existente con mucha complejidad y consultas puede ser un poco problemático para alguien que no tenga una cuota justa de cicatrices de batalla. Considere lo siguiente, pero investigue y construya algunas aplicaciones de balas trazadoras;

1. Spring JDBCTemplate y DAO Pattern Me encantan las soluciones donde JPA / Hibernate simplemente no tiene sentido.
2. MyBatis Nuevamente, otro buen término medio con un poco más de control sobre SQL

Answer 3

Si buscas desarrollar buenos hábitos, leería Code Complete 2 de Steve McConnell.

Answer 4

No descarte un patrón de registro activo como una opción. Eso no tiene que ser un enfoque de entidad EJB. El patrón vale la pena mencionar en mi humilde opinión

Answer 5

JPA puede ser una buena solución a largo plazo. Pero si prefiere estar más cerca del SQL simple, puede considerar otras opciones como el soporte JDBC de Spring Framework .

Tenga en cuenta que no es necesario utilizar otros enlaces de componentes del marco de resorte DI, MVC, etc. para poder utilizar Spring JDBC. Es silencioso y fácil de usar sin otras piezas de marco de resorte. Al usar spring jdbc, no necesita hacer las siguientes tareas en su código:

1. Abra la conexión.
2. Prepare y ejecute la declaración.
3. Configure el ciclo para iterar a través de los resultados (si corresponde).
4. Procese cualquier excepción.
5. Manejar transacciones
6. Cierre la conexión, la declaración y el conjunto de resultados.

Lo que debes hacer es:

1. Definir los parámetros de conexión. (una vez)
2. Especifique la declaración de SQL. (para cada consulta)
3. Declarar parámetros y proporcionar valores de parámetros (cuando se usan declaraciones preparadas)
4. Haz el trabajo para cada iteración. (la primavera hace el recorrido del conjunto de resultados, solo necesita proporcionar lógica para actuar en una sola fila)

Otro beneficio de spring-jdbc es que reemplaza las excepciones comprobadas de JDBC con excepciones sin marcar.