hibernate, ser perezoso o no ser perezoso?

Question

Tengo entity A, que tiene una relación de varios a entity B.

lo tanto, el diseño de la mesa es: A, AB(mapping table), B

para obtener un objeto de la entidad A: me llaman A.getById()getHibernateTemplate().get(A.class, id) que no hace uso de la primavera y de hibernación.

El problema es, el código de veces que siguió solo se necesita un código, a veces subsiguiente continuarán teniendo acceso a la asociada B, por lo que nos gustaría utilizar carga diferida en algunos casos y ansiosos en algunos otros casos. pero el problema es que todo el acceso a la base de datos se proporciona a través del mismo ADao.java, por lo que solo hay un método getById().

¿Debo crear dos versiones del método getById()?

Pero luego para casos más complejos, si A también está unido a C a través de muchos a muchos, entonces podría haber variantes de lazy-loading-C y Eager-loading-C, por lo que las variantes getById() requeridas rápidamente crece exponencialmente

¿cuál es su opinión sobre esta elección?

Gracias

Answer 1

Para consideraciones generales eche un vistazo a los documentos de Hibernate 3.6 sobre fetching strategies. La estrategia de búsqueda predeterminada se define en anotaciones de asignación o en un archivo hbm.xml. Hay tres formas de cambiar dinámicamente de una estrategia de carga lenta predeterminada a una estrategia de carga ansiosa. Los dos primeros requieren implementaciones diferentes de métodos DAO para casos perezoso de carga y uso deseosos de carga:

1. Criteria.setFetchMode() en un Criterios de consulta de Hibernate
2. FETCH de palabras clave en una consulta HQL
3. Desde Hibernate 3.5 (no del todo seguro ahora, tal vez 3.6) existe la tercera opción de usar fetch profiles para cambiar dinámicamente de carga lenta a carga ansiosa.

Un perfil de búsqueda está habilitado/deshabilitado en un ámbito de sesión. Por lo tanto, siempre que el perfil de búsqueda deseado esté configurado en la sesión actual, puede usar el mismo método DAO para una carga diferida así como para un caso de uso de carga ansiosa.

Lo importante a tener en cuenta aquí es que sólo se puede pasar de una estrategia perezosa de carga se define en las anotaciones o en un archivo hbm.xml a una estrategia deseosos de carga y no al revés. Esta restricción es independiente del método utilizado para cambiar la estrategia de búsqueda.

Answer 2

Bueno, describió el problema correctamente. Es solo una compensación entre simplicidad (solo un método) y rendimiento (dos métodos, cada uno devuelve exactamente lo que se necesita). Si el tiempo de respuesta es correcto solo con usar el método simple y cargar las B de forma diferida, entonces no toque nada. Si el tiempo de respuesta es demasiado largo, y ha medido esa carga ansiosa, sería correcto, luego introduzca un nuevo método.

Mantenga las cosas simples, y optimice solo si es necesario. Las asociaciones de carga diferida son rápidas, ya que solo hacen una consulta en una clave externa, que debe indexarse ​​en la base de datos.

Además, no es tan raro cargar dos asociaciones entre muchas asociaciones: es común mostrar todos los productos de una categoría en una página, pero no es común mostrar todas las compras de todos los productos de una categoría.