Hibernate vs Ibatis

[Itchy]

Quisisera discutir acerca de los dos frameworks de persitencias de datos en POO mas utilizados en la actualidad para aclarar sus ventajas y desventajas

ITCHY

[stock]

PUessss de Hibernate te puedo decir que es muy bueno!! unicamente necesitas tener bien diseniada tu base de datos, me refiero a las relaciones y todo eso, lo demas Hibernet se encarga de hacerlo!!

genial!! del otro no te puedo decir nada por que nunca lo e usado

[Itchy]

Bueno yo pienso lo mismo que tu pero en cuanto al manejo de consultas hibernate saca una ligera ventaja ya que
tiene su propio lenguaje "HQL" que lo hace multi-motor de bd eso es uno de los atractivos de hibernate. Te recomiendo que uses el ibatis ya que su fuerte son los triggers y los store procedures chequea http://ibatis.apache.org/downloads.html para los jars, documentacion y demas.

[GreenEyed]

Ummm.... los triggers y los stored procedures no serían el fuerte de... ¿la base de datos? Por mucho Ibatis que le pongas, si la BDD no da soporte para eso...
Yo he usado EJB1.1, 2.1 & hibernate y por lo que he oido Ibatis tiene su fuerte en que te permite un SQL más... libre, en cambio en las otras opciones estás más limitado por el XQL que usen EQL o HQL, pero a cambio te dan otras cosas, como operaciones de mantenimiento sin escribir ni una linea de SQL y portabilidad entre BDD.

Todo tiene sus pros y sus contras.

[Itchy]

cuando yo me referia que el fuerte de ibatis eran lo stores y triggers queria decir que el mapeo en el xml es bien fexible lo que no ofrece el hibernate ya que la llamada de un store cualquiera permite que los resultados se almacen en cursores dependiendo de la bd utlizada lo que hace mas facil el uso de los DynaBean por ejemplo para llenar un Value Object o si se quiere un DTO.
En cambio el hibernate todo lo hace mas laborioso ya que todo tiene que estar previamente mapeado (entity beans) para recien encargarse de la logica de negocios

[GreenEyed]

Los ¿triggers? No se si estamos hablando de los mismos tipos de triggers, por que los que yo digo son internos a la base de datos y no se llaman desde la logica de fuera. ¿Quiza Ibatis tiene otra cosa a la que llama Triggers?

En cuanto a procedures, solo queria decir que el soporte de procedures, asi como de triggers, te lo da la base de datos. Lo que si es cierto es que Ibatis te permite llamar a los stored procedures más.... libremente, que es precisamente la ventaja que comentaba yo que tiene Ibatis. Con Hibernate tambien puedes utilizar una conexion JDBC y hacer tu propia llamada al procedimimiento, pero entonces estas "rompiendo" la portabilidad.
El problema con Ibatis es que es menos "laborioso" montarlo puesto que no tienes que describir objetos en descriptores etc, pero a cambio es mas "laborioso" hacer los mantenimientos básicos, que en Hibernate son un "no-brainer" que dicen los anglos. De igual forma es mas complicado si quieres mantener la misma aplicacion para diferentes bases de datos, ya que te has de trabajar el SQL para cada BDD tu, cuando en Hibernate te lo hace el.

Lo dicho, unas ventajas a cambio de otras, todo es cuestión de elegir.

Por cierto: En Hibernate no se usa el terminio Entity Beans (si te oye Gavin King le da un pasmo ) ya que ese concepto es de los EJB. En Hibernate son simples POJO (la granja de "poyos" los llamo yo, jejeje)

[Itchy]

Aclaro que para ibatis trabaje con power designer para crear todas las entidades con sus respectivos atributos y relaciones mediante un script que se tiene que generar para hacer posible esa funcionalidad me parece ó es la misma "caracteristica" que tiene hibernate

[Guepardo]

Holas, actualmente estamos decidiendo que framework emplear.
Nuestras aplicaciones son un tanto complejas.
Y necesitamos manejar gran cantidad de consultas a Bases de datos (muchas veces de mas de dos tablas), asi como stores o procedimientos almanacenados. Que me recomendarian utilizar: Hibernate o Ibatis.

gracias.

[TolaWare]

No siempre el uso de un framework de persistencia ya hecho es bueno. Hubo un caso en que una aplicacion usando Hibernate, cuando largaba una consulta compleja al framework, este tardaba 4 minutos en responder. Tratando de optimizarlo lo mejor posible,(siempre usando hibernate) se redujo el tiempo a 3 minutos, lo cual era inaceptable para el cliente. Imaginense que le digamos al cliente "haga click aqui y espere 3 minutos a que le aparezca la factura." es algo totalmente inaceptable. Por esta razon se concluyo que desarrollar un framework nuevo para esta aplicacion era lo mejor.

Con esto no trato de desacreditar a hibernate, realmente es un excelente framework, pero esta desarrollado para que trabaje bien en un amplio rango de aplicaciones y como dice el dicho "el que mucho abarca, poco aprieta"

[GreenEyed]

Personalmente yo recomendaría utilizar un framework de persistencia ya hecho... o no usar ninguno. Por que ponerse a hacer uno a estas alturas de la película con todas las opciones que hay y va a haber(JDO, JPA/EJB3, Hibernate, Ibatis...) me parecería un poco reinventar la rueda por que si.

Eso sí, lo mejor de todo es hacer pruebas uno mismo para ver cual se adapta mejor a nuestras necesidades, por que hacerlo de oidas es peligroso. En principio, lo que dices apunta más a Ibatis que a Hibernate o JDO, ya que estos ultimos estan más orientados a modelos de datos orientados a objetos y aunque permiten el acceso directo a tablas, no es para lo que estan pensados principalmente.

Eso si, nada, y repito: nada, sustituye a un buen esquema de base de datos y una optimización de la misma. Por mucho que algunos quieran olvidarse de que hay una BDD por debajo, la realidad es muy terca y nos enseña que esta ahí .

[TolaWare]

basicamente "si no encuentras uno que se adapte a tus necesidades, no uses ninguno" no es un pensamiento con el cual este de acuerdo, pero cada quien es dueño de pensar lo que quiera, y supongo que tendras tus razones para que pienses asi.

Pero como dije antes, esa postura no me parece correcta, ¿porque hay que privarse de desarrollar algo si no encontramos uno que se ajuste a nuestras necesidades?.

Con ese pensamiento, nunca se hubiese desarrollado Linux o emule.

Ademas, si nosotros desarrollamos nuestros propios componentes, tendremos mayor control sobre nuestra aplicacion, y ademas esta sera menos dependiente de productos externos.

Estoy al tanto del costo que esto conlleva: mayor tiempo de desarrollo y por lo tanto mayor costo en el desarrollo.

GreenEyed: no desacredito el uso de Hibernate. Como dije mas arriba, en muchos casos hibernate u otro mapeador o/r, funcionan bien, pero hay algunos casos en que no y es alli donde amerita un desarrollo de un framework nuevo y personalizado.

Otro ejemplo: hace un mes puse un mensaje en foro de programacion preguntando por frameworks de persistencia para C++, la respuesta fue negativa y buscando en varios sitios de desarrollo, en ningun lado encontre lo que necesitaba, por lo que ahora tengo que desarrollar un framework de persistencia para mi aplicación (y no por eleccion).

Saludos. Espero haber aclarado mi punto

[GreenEyed]

Y yo repito: "A estas alturas de la película...". Como ejercicio creativo me parecería bien, pero creo que para este tema en particular hay suficientes soluciones diferentes con bastante rodaje como para inventarse uno una solución desde cero.

Yo soy el primero al que no le importa arremangarse y hacerse su propia implementación, para muestra el framework propio de desarrollo web que mantengo desde hace 8 años y que usamos para hacer nuestras aplicaciones. Y no es ni la primera ni la última cosa que haré por mi cuenta sin usar lo que esta hecho por que no se adapte a lo que necesito.

Sólo digo que, en mi opinión, en este tema en particular en Java el campo esta bastante trillado y que si no te sirve ningún framework de persistencia de los actuales, es seguramente por que no te sirve ningun "framework" y lo mejor es optar por una solución más artesanal sin usar nada más elaborado. Yo cuando tengo una aplicación que no se adapta a las librerías de persistencia actuales normalmente la ataco con unas clases básicas para encapsular JDBC un poco por encima, pero no me hago un framework nuevo ya que hacerlo bien es mucho trabajo y acabaría repitendo lo que ya hay hecho.

Si hablaramos de otros temas, la discusión sería otra y estoy totalmente de acuerdo contigo que no es un principio general, ni mucho menos.

S!

PD: No tengo nada especialmente a favor de Hibernate, así que no pasa nada por "desacreditarlo" . Yo lo uso para algunas cosas y aun así hay cosas que no me gustan o para las que no lo uso por que no me parece adecuado.
PPD: Una pena lo de no tenerlo hecho para C++, por que hacer uno de cero cuesta. Se hace, pero cuesta tiempo que podrías dedicar a otras cosas, como hacer la aplicación en si. Suerte.

[GeovannyAvril]

Bueno, lo cierto es q existen en la actualidad gran variedad de Framework, lo importante antes de escoger cual debe conducir el diseño de mi aplicacion es consultar las ventajas y desventajas que tiene cada uno. Aunque parecerian similares (En cuanto a la persistencia de BD se refiere) cada uno tiene fuertes y debilidades de acuerdo al modelo de negoco el motor de base de datos, el performace de la BD, el problema que el sistema resulve, etc....
De mi parte he trabajado con Ibatis y simplemente lo recomiendo porquesu Simplicidad (Fácil de usar, si sabemos SQL), Curva de aprendizaje baja (muy intuitivo al empezar a usar), se tiene control completo sobre los SQL, Rendimiento: cache fácilmente configurable (LRU, FIFO,
Memory, OSCache), Flexibilidad (statements dinámicos), Permite mapeo directo a XML. Hibernate tiene tambien muchas de estas ventajas, sin embargo las transacciones SQL son transparentes al usuario, la gran diferencia es que Ibatis no es un ORM, lo cual significa en terminos mas claros que el programador tiene que programar el SQL.
Espero haber ayudado.... Bye.