java - Cuándo usar Hibernate/JPA/Toplink?
orm (6)
¿Quieres decir simple JDBC viejo? Un pequeño proyecto podría ser una buena oportunidad para elegir uno de los marcos ORM, especialmente si tiene tiempo.
Sin más información, sin embargo, es difícil proporcionar una recomendación de una forma u otra.
Ahora mismo estoy creando un sitio web extremadamente simple, de aproximadamente 5 páginas. La pregunta es si es excesivo y vale la pena el tiempo para integrar algún tipo de solución de mapeo de bases de datos o si sería mejor usar simplemente JNDI antiguo. Tendré tal vez una docena de cosas que necesito leer / escribir de la base de datos. Creo que tengo una comprensión básica de estas tecnologías, pero aún tomaría muchas referencias a la documentación. ¿Alguien más se enfrentó con la decisión antes?
EDITAR: Lo siento, debería haber especificado JNDI para buscar la conexión de base de datos y JDBC para realizar las operaciones.
La mejor forma de aprender ORM es en un proyecto pequeño. Comience en este proyecto.
Una vez que lo domines, usarás ORM para todo.
No hay nada demasiado pequeño para ORM. Después de su primer par de proyectos, descubrirá que no puede trabajar de otra manera. El mapeo de ORM generalmente tiene más sentido que casi cualquier otra forma de trabajo.
Mi regla de oro es que, si es de solo lectura, estoy dispuesto a hacerlo en JDBC, aunque prefiero usar un proyecto de Hibernate vacío con SQLQuery para aprovechar el mapeo de tipos de Hibernate. Una vez que tengo que escribir, voy con Hibernate porque es mucho más fácil establecer algunos atributos y luego llamar a guardar que establecer cada columna individualmente. Y cuando tiene que comenzar a optimizar para evitar actualizaciones en objetos no modificados, está mucho mejor con un OR / M y su comprobación sucia. Tratar con relaciones de claves foráneas es otro signo de que necesita asignarlo una vez y luego usar los getters. La misma lógica se aplicaría a Toplink, aunque a menos que hayan agregado algo como HQL en los 3 años desde que lo usé, Hibernate sería mucho mejor para este tipo de transición de SQL puro. Tenga en cuenta que no tiene que mapear cada objeto / tabla, solo aquellos en los que hay una clara ventaja. En mi experiencia, la mayoría de los proyectos que no usan un OR / M existente terminan construyendo uno nuevo, lo cual es una mala idea.
Mire las diversas guías toplink aquí, tienen introducción, ejemplos, escenarios, etc.
Parece que sería excesivo para una aplicación muy simple, especialmente si no tiene planes de expandirse nunca. Sin embargo, también parece que valdría la pena usarlos con esta sencilla aplicación para que comprenda mejor cómo funcionan la próxima vez que tenga algo que pueda usar.
Respuesta corta: depende de la complejidad que desee admitir.
Respuesta larga:
En primer lugar, ORM (mapeo relacional de objetos - mapeo de bases de datos como lo llamas) - y JNDI (interfaces de nombres y directorios de Java) son dos cosas diferentes.
El primero, como ya sabe, se utiliza para asignar las tablas de la base de datos a clases y objetos. El segundo es proporcionar un mecanismo de búsqueda de recursos, pueden ser DataSources, Ejb, Colas u otros.
Tal vez tu significa "JDBC".
Ahora en cuanto a su pregunta: si es así de simple, no sería necesario implementar un ORM. Las tablas de números serían de 5 a 10 como máximo, y las operaciones realmente simples, supongo.
Probablemente usar JDBC simple sería suficiente.
Si utiliza el patrón DAO, puede cambiarlo más tarde para que sea compatible con la estrategia ORM si es necesario.
De esta manera: Digamos que tienes la tabla de empleados
Usted crea Employee.java con todos los campos del DB a mano (no debería tomar demasiado tiempo) y un EmployeeDaO.java con métodos como:
+findById( id ): Employee
+insert( Employee )
+update( Employee )
+delete( Employee )
+findAll():List<Employee>
Y la implementación es bastante directa:
select * from employee where id = ?
insert into employee ( bla, bla, bla ) values ( ? , ? , ? )
update etc. etc
Cuando (y si) su aplicación se vuelve demasiado compleja, puede cambiar la implementación de DAO. Por ejemplo, en el método "seleccionar", usted cambia el código para usar el objeto ORM que realiza la operación.
public Employee selectById( int id ) {
// Commenting out the previous implementation...
// String query = select * from employee where id = ?
// execute( query )
// Using the ORM solution
Session session = getSession();
Employee e = ( Employee ) session.get( Employee.clas, id );
return e;
}
Esto es solo un ejemplo, en la vida real puede dejar que la fábrica actual cree el ORM DAO, pero eso es algo atípico. El punto es que puede comenzar de manera simple y, utilizando los patrones de diseño, puede cambiar la implementación más adelante si es necesario.
Por supuesto, si desea aprender la tecnología, puede comenzar con una sola tabla.
La elección de una u otra (solución ORM) depende básicamente de la tecnología que esté utilizando. Por ejemplo, para JBoss u otros productos de código abierto, Hibernate es genial. Es de código abierto, hay muchos recursos de donde aprender. Pero si está utilizando algo que ya tiene Toplink (como el servidor de aplicaciones Oracle) o si la base ya está construida en Toplink, debe permanecer con ese marco.
Por cierto, desde que Oracle compró BEA, dijeron que están reemplazando a Kodo (marco de peresistencia weblogic) con toplink en el ahora llamado "servidor de aplicaciones Oracle Weblogic".
Te dejo algunos recursos donde puedes obtener más información sobre esto:
En este libro "Patrones de arquitectura de aplicaciones empresariales", Martin Fowler, explica dónde usar uno u otro, aquí está el catálogo. Eche un vistazo a Patrones arquitectónicos de origen de datos frente a patrones de comportamiento relacional de objetos: DAO (Data Access Object) es parte del catálogo de patrones de J2EE principal:Este es un tutorial inicial para Hibernate:
La página oficial de Toplink:
Finalmente, "pienso" que lo bueno de JPA es que puedes cambiar de proveedor últimamente.
Comience de manera simple y luego evolucione.
Espero que esto ayude.