OpenXava 4m1 ya está disponible. Como muchos de vosotros ya sabéis OpenXava es un marco de trabajo para desarrollo rápido de aplicacion de gestión en Java orientado al modelo.
Esta versión es el primer hito hacia OX4, cuyo objetivo es mejorar la experiencia del usuario. Hemos añadido jQuery y jQuery UI para incluir diálogo modales. Además tienes más de 35 nuevas características y arreglos sobre 3.1.4, entre las que destacan:
Etiquetas: j2ee, openxava, java, javaee, jpa, framework, frameworks, rapid, development, domaindriven, modeldriven
Aguante Javi, yo hice hace unas semanas hice un sistema con OX
Muy bueno y muy recomendable. Y sobre todo el soporte que tiene es mil veces mejor que el de la mayoría de los productos pagos
Salute, Diego
Enhorabuena, animo y p'alante. Me suena alguna de las mejoras de esta versión... ¿por que será? :D
La verdad es que no tiene mala pinta.
El ida es bastante bueno, aunque el medio elegido no me llega a convence. Es decir, el llenar las clases del dominio(POJOS) de todo tipo de annotations para conseguir validadore, busquedas, editores,.. Prefiero usar algo como OAW(http://www.openarchitectureware.org/) con un cartridge como Sculptor (aunque su enfoque DDD no es mi preferido) y seguir la misma idea de crear un modelo con metainformación de toda la aplicación, a partir del cual se generará la aplicación y podré decidir entre otras cosas, que sistema de persistencia usar (hay vida fuera de JPA).
No obstante montarse un DSL con OAW requiere un ciero tiempo, y entiendo que este framework ya te lo da hecho por lo que puede ser una buena opción en caso de partir de cero.
Hola Anónimo,
el medio elegido no me llega a convence. Es decir, el llenar las clases del dominio(POJOS) de todo tipo de annotations para> conseguir validadore, busquedas, editores,..
La idea es tener toda la información acerca de un concepto de negocio en el mismo sitio. Nosotros empezamos a trabajar con EJB 1.0 cuando las 3 capas eran el "ideal", y CORBA el paraiso al que no podiamos aspirar. El problema de aquello era que cuando tenías que modificar la estructura de los datos o la lógica asociada a ellos (y eso era algo común) debiamos de tocar literalmente decenas de archivos.
Con OpenXava usamos un enfoque basasado en el concepto de Componente de Negocio, donde clasificamos en base a concepto de negocio (Factura, Cliente, Pedido, etc) y no en base a capas tecnológicas (interfaz de usuario, lógica de negocio, base de datos, etc.)
¿Por qué una clase Java con anotaciones y no un DSL? La razón es puramente estratégica. De hecho hasta la versión 2 OpenXava no usaba POJOs sino archivos XML para definir los componentes, y podías generar aplicaciones EJB2, Hibernate o JPA. Y esto todavía está soportado. Es decir, efectivamente OX tenía su propio DSL (aunque con XML).
Pero usando Java con JPA tenemos las siguientes ventajas:
Un DSL puede ser mejor, pero Java es ubicuo.
Y sobre todo, que a los programadores Java les gusta programar en Java, y no con el DSL que tú te puedas inventar. Realmente este cambio hacia POJOs fue fruto de escuchar a la comunidad de desarrolladores OX de aquella época. Y el resultado ha sido muy bueno, la comunidad OX ha aumentado enormemente desde entonces, y los que ya usaban OX2 están encantado con este giro hacia Java.
Curiosamente hace un tiempo escribi un artículo que tiene que ver con lo que tu comentas:
¿Cómo simplificar MDD para acelerar el desarrollo Java Empresarial?
Hola, solo un comentario sobre la frase "La idea es tener toda la información acerca de un concepto de negocio en el mismo sitio."
Esto puede hacer que es único sitio, este sobrecargado de información.
Como siempre, creo que hay que encontrar el equilibirio entre tener 1000 "clases" con 3 lineas o 1 "clase" con 3000 lineas.
Un saludo,
Antonio
Hola Antonio,
Esto puede hacer que es único sitio, este sobrecargado de información
Eso no suele ocurrir, dado que en una aplicación de gestión tienes bastantes conceptos de negocio, por lo que estás obligado a repartir tu código. Por ejemplo, una aplicación de nóminas puedes tener 200 componentes de negocio perfectamente, así que aunque quieras no puedes hacerlo todo en una macroclase.
La realidad es que al final el código del módelo en una aplicación OpenXava es ligeramente superior (por las anotaciones) al de una aplicación hecha con un marco MVC, pero ojo, en OX solo tienes el módelo, así que la cantidad de código total a escribir es muchisimo menor.
A mi personalmente no me importa cuando examino una propiedad o método ver todas sus anotaciones. Pero para los que les moleste ver tanta información a la vez, un plugin de Eclipse que filtre visualmente las anotaciones a ver por páquete, podría ser una buena forma de ver la misma clase de diferentes perspectivas.
Escribe tu comentario