2008-09-23 17 views
7

Ahora mismo estoy haciendo 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?Cuándo usar Hibernate/JPA/Toplink?

EDITAR: Lo siento, debería haber especificado JNDI para buscar la conexión de base de datos y JDBC para realizar las operaciones.

Respuesta

17

Respuesta corta: Depende de la complejidad que desee admitir.

Respuesta larga:

En primer lugar, ORM (mapeo objeto-relacional - mapeo de base de datos como se llame -) y JNDI (Java Naming and Directory Interfaces) son dos cosas diferentes.

El primero como usted 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 su significado es "JDBC".

Ahora en cuanto a su pregunta: Si es así de simple puede que no sea 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 usa el patrón DAO, puede cambiarlo más adelante para admitir la estrategia ORM si es necesario.

De esta manera: Digamos que tiene la tabla de empleados

crear el Employee.java con todos los campos de la base de datos con la mano (que no debería tomar mucho tiempo) y un EmployeeDaO.java con métodos como:

+findById(id): Employee 
+insert(Employee) 
+update(Employee) 
+delete(Employee) 
+findAll():List<Employee> 

y la aplicación es muy sencillo:

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 que m ay 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 sólo un ejemplo, en la vida real es posible que deje la fábrica abstact crear el DAO ORM, pero eso es offtopic.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 1 mesa.

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, dado 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".

os dejo algunos recursos donde puede obtener más información sobre esto:


en este "Patrones de Arquitectura de aplicaciones de empresa" libro, Martin Fowler, explica dónde utilizar una u otra, aquí está el catálogo . Echar un vistazo a Fuente de Datos patrones arquitectónicos frente a patrones de comportamiento-relacional de objetos:

PEAA Catalog


DAO (Data Access Object) es parte del catálogo de patrones núcleo J2EE:

The DAO pattern


Este es un tutorial básico para Hibernate:

Hibernate


La página oficial de Toplink:

Toplink


Finalmente I "piensa" el buen pensar de APP es que puede cambiar de proveedor últimamente.

Comience de forma simple y luego evolucione.

Espero que esto ayude.

1

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.

1

¿Quiere decir plain old JDBC? Un pequeño proyecto podría ser una buena oportunidad para elegir uno de los marcos ORM, especialmente si tiene tiempo.

Sin embargo, es difícil proporcionar una recomendación de una manera u otra.

1

Mi regla de oro es 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.

1

El mejor forma de aprender ORM es en un proyecto pequeño. Comience en este proyecto.

Una vez que lo domine, usará 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.

Cuestiones relacionadas