tutorial - Guerra de los marcos de Java: Spring and Hibernate
spring stack (18)
Mis desarrolladores están librando una guerra civil. En un campamento, han abrazado Hibernate y Spring. En el otro campo, han denunciado los marcos, sin embargo, están considerando Hibernate.
La pregunta es: ¿hay sorpresas desagradables, debilidades o caídas en boxes que los nuevos conversos de Hibernate-Spring puedan tropezar?
PD: Tenemos una biblioteca DAO que no es muy sofisticada. Dudo que tenga la riqueza de Hibernate, pero está alcanzando algún tipo de madurez (es decir, no se ha modificado en los últimos proyectos incluidos).
@slim - Estoy contigo otra vez esta mañana.
Suena como un caso clásico de síndrome no inventado aquí . Si no están interesados en la primavera, deberían considerar otras opciones en lugar de crear su propio marco (ya sea que lo reconozcan o no). Guice viene a mi mente como una posibilidad. También picocontainer. Hay otros por ahí, dependiendo de lo que necesita.
En cuanto a Hibernate: una herramienta muy buena para la aplicación que trata con un esquema de base de datos que cambia rápidamente, una gran cantidad de tablas, realiza muchas operaciones CRUD simples. Los informes con consultas complejas involucradas son bastante menos manejados. Pero en estos casos prefiero mezclar en JDBC o consultas nativas. Entonces, para una respuesta corta: creo que el tiempo que pasé aprendiendo Hibernate es una buena inversión (dicen que cumple con los estándares EJB3.0 y JPA, también, pero eso no entró en la ecuación cuando lo evalué para mi personal utilizar).
En cuanto a Spring ... ver The Bile Blog :)
Recuerde: los marcos no son balas de plata , pero tampoco debe reinventar la rueda .
En mi opinión, la mayor ventaja de Spring es que fomenta y permite mejores prácticas de desarrollo, en particular, acoplamiento flexible, pruebas y más interfaces. Hibernate sin Spring puede ser muy doloroso, pero los dos juntos son muy útiles.
Volver a adaptar un proyecto existente a cualquier marco va a ser doloroso, pero el proceso de refactorización a menudo tiene serios beneficios para el mantenimiento a largo plazo.
Esto es una cosa (podría recordar) en la que caí cuando estaba en mis días de Hibernate. Cuando elimina (varios) objetos secundarios de una colección (en una entidad padre) y luego agrega entidades nuevas a la misma colección en una transacción sin enrojecimiento en el medio, Hibernate hará "insertar" antes de "eliminar". Si la tabla secundaria tiene una restricción única en una de sus columnas, y está esperando que no la viole ya que ya ha borrado algunos datos (como yo), prepárese para frustrarse. El foro de Hibernate sugiere:
- Era un defecto de diseño de DB, rediseño;
- flush (o commit if if) entre las eliminaciones y las inserciones;
No pude hacer las dos cosas y terminé retocando la fuente de Hibernate y volviendo a compilar. Fue solo 1 línea de código. Pero el esfuerzo por encontrar esa línea equivale a aproximadamente 27 tazas de café y 3 noches de insomnio.
Este es solo un ejemplo de los problemas y peculiaridades que puede terminar al usar Hibernate sin un verdadero experto en su equipo (experto: alguien con el conocimiento adecuado sobre la filosofía y el funcionamiento interno de Hibernate). Su problema, la solución, el litro de café y el conteo nocturno sin dormir pueden variar. Pero se entiende la idea.
Han denunciado los marcos ?
Eso es loco. Si no usa un marco comercial, entonces cree el suyo propio. Todavía es un marco.
He hecho un montón de desarrollo de Spring / Hibernate. Con el tiempo, la forma en que las personas usaban ambas en combinación ha cambiado un poco. El enfoque original de HibernateTemplate ha demostrado ser difícil de depurar ya que traga y envuelve excepciones útiles; ¡habla directamente con la API de Hiberante!
Siga buscando en el SQL generado (configure su registro de desarrollo para mostrar SQL). Tener una capa de abstracción en la base de datos no significa que ya no tenga que pensar en SQL; no obtendrás un buen rendimiento si no lo haces.
Considera el proyecto. Elegí iBatis sobre Hibernate en varias ocasiones en las que teníamos requisitos de rendimiento estrictos, esquemas heredados complejos o buenos DBa capaces de escribir SQL excelente.
He usado Hibernate varias veces en el pasado. Cada vez que me he encontrado con casos extremos donde la determinación de la sintaxis se convirtió en una búsqueda del tesoro a través de la documentación, Google y versiones anteriores. Es una herramienta poderosa pero mal documentada (la última que miré).
En cuanto a Spring, casi todos los trabajos que he entrevistado o visto en los últimos años han sido de Spring, realmente se han convertido en el estándar de facto para Java / web. Usarlo ayudará a sus desarrolladores a ser más comercializables en el futuro, y lo ayudará, ya que tendrá un gran grupo de personas que entenderán su aplicación.
Escribir su propio marco es tentador, educativo y divertido. No tan bueno en los resultados.
Hibernate tiene caprichos, pero es porque el problema que está tratando de resolver es complejo. Cada vez que alguien se queja sobre Hibernate, les recuerdo todo el aburrido código DAO que tendrían que mantener si no lo estuvieran usando.
Algunos consejos:
- Hibernate no es un sustituto de un buen diseño de base de datos. Los esquemas de Hibernate están bien, pero tendrá que modificarlos ocasionalmente
- Eventualmente tendrá que entender cómo Hibernate floja carga clases y cómo eso afecta las cosas. Hibernate modifica el bytecode de Java y, tarde o temprano, tendrá que profundizar en las profundidades solo para explicar por qué los enlaces de objeto son nulos.
- Usa anotaciones si puedes.
- Tómese el tiempo para aprender las técnicas de ajuste de rendimiento de Hibernate, le ahorrará a largo plazo.
La carga diferida es el gran problema en las aplicaciones MVC que usan Hibernate para su marco de persistencia. Usted carga el objeto en el controlador y lo pasa a la vista JSP. Algunos o todos los miembros de la clase tienen un proxy y todo explota porque la sesión de Hibernate se cerró cuando el controlador se completó.
Deberá leer el artículo Open Session in View para comprender el problema y obtener una solución. Si está utilizando Spring, este artículo de blog describe la solución de Spring para la sesión abierta en cuestión de vista.
La respuesta principal menciona que Hibernate está poco documentado. Estoy de acuerdo en que el manual de referencia en línea podría ser más completo. Sin embargo, un libro escrito por los autores de Hibernate, '' Persistencia de Java con Hibernate '' es una lectura obligada para cada usuario de Hibernate y muy completo.
Los marcos no son malvados. incluso el SDK de Java es un marco.
Lo que probablemente pelearán es la proliferación del marco . No debería traer un marco a un proyecto solo por el momento, debería aportar un valor constante en un tiempo razonable. Cada marco requiere una curva de aprendizaje, pero debe recompensarlo con mayor productividad y características más adelante.
Si tiene problemas con el código que es difícil de depurar debido al uso inconsistente de la base de datos, los mecanismos de caché complicados o una miríada de otras razones. Hibernate agregará un gran valor. aparte de la curva de aprendizaje (que me llevó aproximadamente 1 mes de trabajo práctico) no hubo inconvenientes, siempre que haya alguien a su alrededor que le explique los conceptos básicos.
Me parece realmente útil utilizar marcos bien conocidos como Hibernate porque encaja tu código en un molde específico o una forma de pensar. Es decir, ya que estás usando Hibernate, escribes el código de cierta manera, y la mayoría, si no todos, los desarrolladores que conocen Hibernate podrán seguir tu línea de pensamiento con bastante facilidad.
Hay una desventaja en esto, por supuesto. Antes de que te conviertas en un desarrollador de Hibernate, vas a descubrir que estás tratando de encajar un cuadrado en un agujero circular. Usted SABE lo que quiere hacer y cómo se suponía que debía hacerlo antes de que Hibernate entrara en escena, pero encontrar la forma de hacerlo de Hibernate puede llevar ... bastante tiempo.
Aún así, para las empresas que frecuentemente contratan consultores (que necesitan comprender una gran cantidad de código fuente en un corto período de tiempo) o donde los desarrolladores inician sesión y abandonan con frecuencia, o donde simplemente no quiere apostar que sus desarrolladores clave Quédese para siempre y nunca cambie de trabajo. Creo que Hibernate y otros marcos estándar son una idea bastante buena.
/As
No he trabajado mucho con Java, pero sí trabajé en grandes grupos de desarrolladores de Java. La impresión que tengo es que Spring está bien. Pero todos estaban molestos con Hibernate. Mitad del equipo si se le pregunta "Si pudieras cambiar una cosa, ¿qué cambiarías?" y dirían "Deshazte de Hibernate". Cuando comencé a aprender Hibernate me pareció increíblemente complejo, pero no aprendí lo suficiente (afortunadamente me he mudado) para saber si la complejidad estaba justificada o no (tal vez era necesario resolver algunos problemas complejos).
El equipo se deshizo de Spring en favor de Guice, pero eso fue más como un cambio político, al menos desde mi punto de vista y otros desarrolladores con los que he hablado.
Si tiene una base de datos bastante compleja, Hibernate puede no ser para usted. En el trabajo, tenemos una base de datos bastante compleja con muchos datos, y Hibernate en realidad no nos funciona. Empezamos a usar iBATIS en su lugar. Sin embargo, conozco a muchas tiendas de desarrollo que usan Hibernate con éxito, y que hace mucho trabajo duro para usted, así que vale la pena considerarlo.
Spring es una buena herramienta si sabes cómo usarla correctamente.
Diría que los marcos definitivamente son algo bueno, como han señalado otros, no desea reinventar la rueda. Spring contiene muchos módulos que significarán que no tendrás que escribir tanto código. ¡No sucumba al síndrome de "No se inventó aquí"!
Siempre he descubierto que Hibernate es un poco complejo y difícil de aprender. Pero como JPA (Java Persistence API) y EJB (Enterprise Java Beans) 3.0 han existido por un tiempo, las cosas se han vuelto mucho más fáciles, prefiero anotar mis clases para crear mapeos a través de JavaDoc o XML. Mira el soporte en Hibernate . La ventaja añadida es que es posible (pero no sin esfuerzo) cambiar el marco de la base de datos más adelante si es necesario. He usado OpenJPA con excelentes resultados.
Últimamente he estado usando JCR (Java Content Repository) más y más. Me encanta la forma en que mis módulos pueden compartir un solo almacenamiento de datos y que puedo permitir que la estructura y las propiedades evolucionen. Me resulta mucho más fácil trabajar con nodos y propiedades que mapear mis objetos en una base de datos. Una buena implementación es Jackrabbit .
En cuanto a Spring, tiene muchas características que me gustan, pero la cantidad de XML que se necesita para configurar significa que nunca lo usaré. En cambio, utilizo Guice y me encanta.
Para resumir, les mostraría a los desarrolladores que dudan cómo Hibernate les hará la vida más fácil. En cuanto a Spring, verificaría seriamente si Guice es una alternativa viable y luego trataré de mostrar cómo Spring / Guice hace que el desarrollo sea mejor y más fácil.
Spring e Hibernate definitivamente hacen la vida más fácil. Comenzar con ellos puede tomar un poco de tiempo al principio, pero seguramente se beneficiará de ello más adelante. Ahora que el XML está siendo reemplazado por anotaciones, tampoco necesita escribir cientos de líneas de XML.
Es posible que desee considerar AppFuse para reducir su curva de aprendizaje: generar una aplicación, estudiarla y adaptarla, y listo.
Spring e Hibernate son marcos que son difíciles de dominar. Puede que no sea una buena idea usarlos en proyectos con plazos ajustados mientras aún intentas descubrir los marcos.
Los beneficios de los marcos son, básicamente, tratar de proporcionar una plataforma para permitir que los códigos consistentes sean productos. A partir de la experiencia, es recomendable que los desarrolladores tengan experiencia con los marcos en la configuración de las mejores prácticas.
Dependiendo del diseño de su aplicación y / o base de datos, también hay peculiaridades que deberá sortear para asegurarse de que los marcos no obstaculicen el rendimiento.
Tengo que estar de acuerdo con muchas publicaciones sobre esta. He usado ambos, ampliamente, en una variedad de configuraciones. Si pudiera deshacer una decisión de diseño, sería utilizar Hibernate. De hecho, presupuestamos un lanzamiento en uno de nuestros productos para cambiar a Hibernate por iBatis y Spring-JDBC por un enfoque mejor de todos los mundos. Puedo hacer que un nuevo desarrollador se ponga al día usando Spring-JDBC, Spring-MVC, Spring-Ioc e iBatis más rápido que si solo les hubiera encargado Hibernate.
Hibernate es demasiado complicado para este desarrollador de KISS. Y que Dios lo ayude con la hibernación si su DBA ve el SQL generado que ve la base de datos y lo envía de regreso con versiones optimizadas.