Foros del Web » Programación para mayores de 30 ;) » Java »

Hibernate vs Ibatis

Estas en el tema de Hibernate vs Ibatis en el foro de Java en Foros del Web. 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...
  #1 (permalink)  
Antiguo 20/12/2005, 13:06
Avatar de Itchy  
Fecha de Ingreso: diciembre-2005
Mensajes: 18
Antigüedad: 18 años, 11 meses
Puntos: 0
Hibernate vs Ibatis

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
  #2 (permalink)  
Antiguo 21/12/2005, 19:13
Avatar de stock  
Fecha de Ingreso: junio-2004
Ubicación: Monterrey NL
Mensajes: 2.390
Antigüedad: 20 años, 5 meses
Puntos: 53
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
  #3 (permalink)  
Antiguo 22/12/2005, 11:05
Avatar de Itchy  
Fecha de Ingreso: diciembre-2005
Mensajes: 18
Antigüedad: 18 años, 11 meses
Puntos: 0
Sonrisa Respuesta

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.
  #4 (permalink)  
Antiguo 22/12/2005, 14:46
 
Fecha de Ingreso: octubre-2003
Mensajes: 3.578
Antigüedad: 21 años, 1 mes
Puntos: 51
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.
  #5 (permalink)  
Antiguo 23/12/2005, 10:10
Avatar de Itchy  
Fecha de Ingreso: diciembre-2005
Mensajes: 18
Antigüedad: 18 años, 11 meses
Puntos: 0
tu crees???

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
  #6 (permalink)  
Antiguo 23/12/2005, 12:33
 
Fecha de Ingreso: octubre-2003
Mensajes: 3.578
Antigüedad: 21 años, 1 mes
Puntos: 51
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)
  #7 (permalink)  
Antiguo 27/12/2005, 09:36
Avatar de Itchy  
Fecha de Ingreso: diciembre-2005
Mensajes: 18
Antigüedad: 18 años, 11 meses
Puntos: 0
Que quieres decir con describir objetos en descriptores????

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
  #8 (permalink)  
Antiguo 20/03/2006, 09:11
 
Fecha de Ingreso: marzo-2006
Mensajes: 1
Antigüedad: 18 años, 8 meses
Puntos: 0
Hibernate vs Ibatis

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.
  #9 (permalink)  
Antiguo 22/05/2006, 13:09
Avatar de TolaWare
Colaborador
 
Fecha de Ingreso: julio-2005
Mensajes: 4.352
Antigüedad: 19 años, 4 meses
Puntos: 24
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"
__________________
http://blog.tolaware.com.ar -> Blog de Java, Ruby y Linux
  #10 (permalink)  
Antiguo 22/05/2006, 15:37
 
Fecha de Ingreso: octubre-2003
Mensajes: 3.578
Antigüedad: 21 años, 1 mes
Puntos: 51
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í .
  #11 (permalink)  
Antiguo 24/05/2006, 09:01
Avatar de TolaWare
Colaborador
 
Fecha de Ingreso: julio-2005
Mensajes: 4.352
Antigüedad: 19 años, 4 meses
Puntos: 24
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
__________________
http://blog.tolaware.com.ar -> Blog de Java, Ruby y Linux
  #12 (permalink)  
Antiguo 24/05/2006, 10:30
 
Fecha de Ingreso: octubre-2003
Mensajes: 3.578
Antigüedad: 21 años, 1 mes
Puntos: 51
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.
  #13 (permalink)  
Antiguo 28/12/2007, 08:31
 
Fecha de Ingreso: diciembre-2007
Mensajes: 1
Antigüedad: 16 años, 10 meses
Puntos: 1
Mensaje Re: Hibernate vs Ibatis

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.
Atención: Estás leyendo un tema que no tiene actividad desde hace más de 6 MESES, te recomendamos abrir un Nuevo tema en lugar de responder al actual.
Respuesta

SíEste tema le ha gustado a 2 personas (incluyéndote)




La zona horaria es GMT -6. Ahora son las 13:51.