2010-12-03 9 views
25

En la última vez escuché muchas quejas sobre la hibernación. Y de hecho también tengo algunas experiencias dolorosas con Hibernate. Entonces leo sobre Ebean y Siena.¿Cuán maduro es Ebean o Siena?

Ambos tienen enfoques interesantes. Desafortunadamente, las capas de acceso a la base de datos son muy fáciles de escribir, pero si su proyecto crece y usted tiene que manejar grandes tablas de bases de datos, usted sabrá si son buenas o no. Entonces es realmente difícil evaluar tal herramienta. Hibernate es muy conocido y puede estar seguro de que puede resolver su problema con él. En algún momento necesitas aprender mucho, pero puedes resolverlo.

¿Cómo es con Ebean? ¿Hay alguna aplicación del mundo real? ¿Qué bases de datos son compatibles? ¿Es confiable?

Después de buscar un poco más veo que hay muchos marcos ORM, ¿hay al menos uno confiable?

+0

¿Podría agregar algunos detalles sobre los problemas que encontró con Hibernate? Eso nos ayudará a eliminar los marcos ORM con las mismas limitaciones. – mlschechter

+0

Well Hibernate se vuelve difícil para batchjobs, donde realizó muchas operaciones de escritura. Además, Hibernate tiene a menudo algunos efectos sorprendentes, por ejemplo, si tiene crear o cambiar un objeto, se guardará automáticamente. Para dejarlo en claro, Hibernate es un buen marco confiable, pero es complejo y complicado. Si eres un experto en hibernación, está muy bien, pero de lo contrario a veces puedes perder todo un día de desarrollador al tratar de entender el comportamiento. Siena y Ebean prometen ser simples (lo que es fácil de probar) y confiables también (que nadie debe confirmar). – niels

Respuesta

15

Rob (Ebean Committer) aquí.

Ebean tiene aproximadamente 4+ años. Yo diría que ya está bastante maduro. Los DB soportados incluyen Oracle, MySql, Postgres, H2 y SQL Server (y recientemente SQLite). Ebean está haciendo cosas que otros ORM no son como Autofetch (sintonización automática de consultas), así que no sé cómo encajar eso en una "calificación de madurez".Sin embargo, la comunidad de Ebean es relativamente pequeña, por lo que es probable que deba recurrir al grupo de Google Ebean para atraerlos.

¿Alguna aplicación del mundo real? Sí, pero es mejor preguntarle a la comunidad Ebean sobre eso realmente. Ciertamente, existe un buen soporte para el procesamiento por lotes (tamaño de lote, persistencia de una transacción en cascada, etc.) y un gran soporte de consultas que no veo en JPA, etc. (es posible que obtenga algo similar con el soporte Sessionless de Hibernate).

Afortunadamente, esto podría responder algunas partes pequeñas de su pregunta de todos modos.

Cheers, Rob.

+0

Gracias, esta fue de hecho una respuesta con ayuda. – niels

+0

Hola Rob, veo que mantienes los repositorios en github, y aprecio la gran utilidad de Ebean, pero tengo problemas para encontrar documentación actualizada. Las cosas en http://www.avaje.org/ parecen ser muy antiguas. ¿Hay algún Java-docs o guías recientes en alguna parte? – area5one

+1

@ area5one Los documentos son WIP en este momento - puede ver el estado actual en: http://ebean-orm.github.io/ Eso está lejos de completarse, pero durante el próximo mes buscaré completar los nuevos documentos/sitio web. –

1

Hemos tenido una gran experiencia con MyBatis, que no es un ORM per se, sino otra clase de administrador de persistencia, un SQL Mapper. Utilizándolo, comienza con sentencias de SQL y lo dirige sobre cómo mapear filas de resultados en POJO. Es conceptualmente fácil de entender y sintonizar con poca magia dentro. Es ideal si se siente cómodo con SQL o necesita trabajar con un esquema establecido.

+1

Sí, lo sé, trabajé con iBatis antes y creo que es confiable. Las limitaciones son la abstracción faltante del sistema de base de datos. Si debe soportar múltiples sistemas de bases de datos como Oracle, DB2, Postgres y frameworks H2 como Hibernate son realmente útiles. – niels

0

¿Qué hay de usar EB3, con por ejemplo JBoss (www.jboss.org)?

+0

Bueno, busco una solución simple. Un entorno JEE no encaja en esto. – niels

6

Actualmente soy un desarrollador de Siena, pero no desde hace mucho tiempo. Permítanme explicar por qué me convertí en desarrollador de este proyecto. Fui a Siena porque quería usar Play + GAE y Siena parecía ser un buen comienzo para GAE DB y realmente quería evitar JDO/JPA. Entonces, comencé a apreciar realmente Siena por su enfoque sencillo, ligero y fácil, y por sus API tan simples. No pretende ser la capa de abstracción todo en uno como JDO y la mayor API estándar de DB como JPA. Realmente me hizo pensar en las API de DB de Python/Ruby y realmente encaja con mi punto de vista: quiero una simple API de DB que me permita resolver la gran mayoría de mis problemas y cuando tenga un problema más complejo, usaré las API de la capa inferior, pero ciertamente no una capa de abstracción, como la hibernación.

La posibilidad de hacer que mi código funcione en GAE DB o JDBC también fue un buen aspecto. Una vez más, Siena no pretende proporcionar exactamente las mismas cosas en ambos mundos porque SQL y NoSQL no son realmente compatibles (pero ORM no es realmente compatible con el modelo SQL :)). Pero una vez más, es bastante práctico poder confiar en las mismas API en varios DB.

Finalmente, la biblioteca es UNA jarra y no tiene que recuperar todo el universo para usarla.

Por lo tanto, me hice cada vez más comprometido con Siena porque quería formar parte de esta pequeña y agradable aventura. Ahora el equipo de siena está trabajando en una nueva versión manteniendo las mismas API simples, aportando nuevas características interesantes y mejorando realmente todo el código backend para que sea aún más fácil extenderlo para el nuevo soporte de bases de datos. Siena es una API pragmática impulsado por la experiencia del usuario y por eso me gusta;)

Pascal

+0

Gracias por compartir su experiencia, incluso si no muestra qué tan madura es. Lo que no entiendo es por qué no puedo cambiar entre GAE y JDBC. Pensé que este era el gran beneficio de Siena. Quiero decir, de lo contrario, parece más inteligente usar un "ORM-Mapper" específico. – niels

+1

Nunca dije que no puedes cambiar entre GAE y JDBC con Siena: D ... PUEDES cambiar y como dijiste, este es uno de los grandes beneficios de Siena. Pero no decimos que SIEMPRE pueda cambiar entre ambos porque no todo es posible entre SQL y NoSQL. A veces, debe diseñar sus modelos específicamente para NoSQL o SQL para que sean eficientes ... No pretendemos resolver todos los problemas entre NoSQL y SQL porque sería una mentira. Pero en la gran mayoría de los casos, el interruptor funcionará sin ningún problema. – mandubian

+0

En cuanto a la madurez, no soy realmente la persona adecuada, ya que estoy programando para Siena por el momento:) ... Pero sé que la gente lo usa en producción y eligieron Siena contra JDO/JPA u otras cosas para poder tener una API muy simple con una capa delgada entre su código y la base de datos ... Lo que es seguro es que el código es muy pequeño, solo necesitas una jarra y la curva de aprendizaje es muy corta ... Actualmente estamos limpiando el código/diseño muy cuidadosamente e implementando muchas pruebas, así que creo que la calidad de Siena crecerá y crecerá ... ¡No dude en hablar directamente con el grupo Siena si necesita algo! – mandubian

1

Además Ebean y Siena:

Puede probar JIRM que se centra en CRUDing objetos inmutables (si, soy el autor).

También hay jOOQ y Joist.

Creo que JIRM minimiza el número de DTO porque los objetos de dominio son inmutables y no heredan, implementan y/o no están "mejorados/instrumentados". Tal no es lo mismo con Siena y Ebean.

Además, como los objetos son inmutables, se centra más en la actualización por columna que en todo el objeto, lo cual tiene más sentido teniendo en cuenta las interfaces AJAX actuales (en comparación con el antiguo POST todo el modelo de frijol).

Cuestiones relacionadas