29/08/2003, 15:50
| |||
| |||
| Jdo Hola, alguien se ha peleado con alguna versión de JavaDataObjects que no sea comercial?? no he encontrado ninguna que me pareciera que estaba en una versión más o menos estable...de hecho si encuentro una que solo tenga testeada la implementación de la persistencia para Oracle8i y 9i ya me vale... si de paso saben algunos links interesantes de JDO y han probado alguna implementación comercial y quieren comentarla mejor que mejor ...  Saludos,  |
|
01/09/2003, 19:44
| ||||
| ||||
| Castor funciona con Oracle8i y 9i, me consta, en estos momentos estoy haciendo pruebas con Hibernate, pero me esta causando algunos problemillas, en cuanto te pueda comentar algo acerca de este ultimo, lo hare... Saludos |
|
02/09/2003, 04:22
| |||
| |||
| Hola, si bien Castor y Hibernate son muy buenos motores de persistencia (con un tiempo ya en el mercado) ninguno de ellos cumple el estandar JDO 1.0, yo he trabajado con Hibernate más o menos bien...aunque mi interés es en trabajar con una implementación de JDO porque en mi opinión el estándar a la larga es el que se va a imponer... Esta semana he probado Speedo (JORM) y de momento salvo algunas deficiencias (aún no soporta herencia, hay poca documentación) es un producto bastante bueno. Última edición por zyron; 02/09/2003 a las 04:30 |
|
02/09/2003, 11:42
| ||||
| ||||
| Hola, Francamente no creo que se impongan los motores de persisitencia... de pensar asi, todos los actuales desarrollos de aplicaciones estarian implementadas bajo EJB's Entity Beans, lo cual, si bien componen una buena parte del desarrollo de las actuales aplicaciones, no podemos afirmar que esta tecnologia (que ya va en su version 2.1, esto es, que no es muy nueva) se imponga sobre los desarrollos de Session Beans o de simples arquitecturas MVC. Si bien son muy buenos las herramientas que ya en este momento existen para desarrollo de JDO, como por ejemplo los plug-ins para el Hibernate del Eclipse o InteliJ, y si bien es cierto que representan una excelente opcion para un desarrollo de una aplicacion de un buen tamaño, hay que considerar lo dificil que resulta que estos estandares (asi como en su momento los Entity Beans de SUN) 'predominen' por sobre otras soluciones. |
|
02/09/2003, 13:59
| |||
| |||
| La gran ventaja es que no dependes de ningún fabricante, ni de la continuidad de ningún proyecto. Si te casas con JDO y fabricante abandona el producto siempre puedes pasarte a otro fabricante o a otro proyecto Opensource... Si te casas con Hibernate o Castor y abandonan la continuidad de su proyecto..estás perdido...eso es un problema...porque seguramente en tu empresa actualizan el soft de bases de datos y si tu motor de persistencia deja de soportarlo... Bueno, en resumen que yo prefiero los estándares porque me aseguran una continuidad... Además, creo que las especificaciones Java están para algo...fíjate que en el momento que aparece un estándar enseguida la mayoría de paquetes/proyectos lo adaptan...Jonas tiene el proyecto Speedo, JBoss tiene un proyecto JDO, etc... Cuando dices "no creo que se impongan los motores de persistencia" me echo un poco las manos a la cabeza...ya que a nivel de arquitectura de software òbviamente tener un motor de persistencia es una muy buena opción sea del tipo que sea (por cambiabilidad, por extensibilidad, no dependencia del modelo relacional)...y más en la filosofía Java ... Otra cosa, dices: "Si bien son muy buenos las herramientas que ya en este momento existen para desarrollo de JDO, como por ejemplo los plug-ins para el Hibernate del Eclipse o InteliJ"...creo que te lías un poco...Hibernate no es JDO...Eclipse tiene otros plug-ins que si que son JDO... Y finalmente, hay muchos estandares Java que son de uso más que común, y si no que son los JSP?? Los EJB están más que establecidos...cuantos servidores de aplicaciones J2EE conoces que no soporten EJB?? yo excepto los que ya han abandonado su desarrollo ninguno... |
|
02/09/2003, 15:56
| ||||
| ||||
| La gran ventaja es que no dependes de ningún fabricante, ni de la continuidad de ningún proyecto. Si te casas con JDO y fabricante abandona el producto siempre puedes pasarte a otro fabricante o a otro proyecto Opensource... --> Ese es un estandar, asi sea JDO, J2EE, EJB o lo que sea, sin embargo, es absurdo dejarse deslumbrar por cada estandar nuevo que va a salir al mercado Si te casas con Hibernate o Castor y abandonan la continuidad de su proyecto..estás perdido...eso es un problema...porque seguramente en tu empresa actualizan el soft de bases de datos y si tu motor de persistencia deja de soportarlo... --> Nadie ha hablado de casarte con Hibernate ni con Castor, eso es tan volatil como casarte con cualquier otra tecnologia Bueno, en resumen que yo prefiero los estándares porque me aseguran una continuidad... --> Que bueno que lo hagas, para eso son... Además, creo que las especificaciones Java están para algo...fíjate que en el momento que aparece un estándar enseguida la mayoría de paquetes/proyectos lo adaptan...Jonas tiene el proyecto Speedo, JBoss tiene un proyecto JDO, etc... --> No podemos decir que Jonas o que JBoss acaparen la mayoria del mercado, cuando me digas que estos proyectos son implementados por BEA Weblogic, SunOne Application Server o IBM Websohere, tal vez podamos creer que dichos proyectos hayan madurado, mientras, creo que no podemos afirmar nada Cuando dices "no creo que se impongan los motores de persistencia" me echo un poco las manos a la cabeza...ya que a nivel de arquitectura de software òbviamente tener un motor de persistencia es una muy buena opción sea del tipo que sea (por cambiabilidad, por extensibilidad, no dependencia del modelo relacional)...y más en la filosofía Java ... --> Son una excelente opcion, solo que compara la cantidad de desarrollos con esta tecnologia contra un desarrollo con otras herramientas Otra cosa, dices: "Si bien son muy buenos las herramientas que ya en este momento existen para desarrollo de JDO, como por ejemplo los plug-ins para el Hibernate del Eclipse o InteliJ"...creo que te lías un poco...Hibernate no es JDO...Eclipse tiene otros plug-ins que si que son JDO... Y finalmente, hay muchos estandares Java que son de uso más que común, y si no que son los JSP?? Los EJB están más que establecidos...cuantos servidores de aplicaciones J2EE conoces que no soporten EJB?? yo excepto los que ya han abandonado su desarrollo ninguno... ---> Aqui llegamos al punto que queria llegar, el que los JSP y los EJB's esten consagrados y totalmente implementados (hay que tomar en cuenta tambien que estos son estandares de J2EE, a diferencia de JDO) no significa que 'la tendencia vaya hacia alla'. Yo te pregunto, los JSP's son la tendencia y los desarrollos actuales incluyen necesariamente desarrollos de JSP's o EJB's??? NO, y eso es que estamos hablando de J2EE. Sin embargo existen tantas mas tendencias actualmente que si antes alguien te hubiera escuchado decir 'el mercado se mueve hacia los JSP's' o 'hacia los EJB's' ahora se reiria de ti... Y mucha gente lo hizo, creyo que Java era lo maximo, que todo iba a ser java en poco tiempo, yo te pregunto ¿es asi? NO. Me parece que deslumbrarse por un nuevo estandar y creer que es la tecnologia del futuro es algo ilogico por buena que sea esta tecnologia, porque siempre hay alguien preparando algo mejor. Yo creo que en este momento tu no implementas arquitecturas elegantes ni motores de persistencia, ahora, implementas soluciones, y finalmente, no importa con que lo hiciste. Volviendo a los EJB's, creeme, yo soy el primer descepcionado de los resultados obtenidos con ellos, porque no fueron la panacea que todo munco creia, aun cuando lo encuentres en todos los application server del mercado y que tengan un buen resultado, creo que ni ellos mismos resultaron ser lo que todo mundo creia que eran... Ahora otra cosa mas, solo yo te pregunto, cuanto tiempo te lleva la implementacion de un motor de persistencia? Cuanto el de un Entity Bean? Cuanto una simple arquitectura MVC? Cual es TU curva de aprendizaje y cual la de tus programadores? Piensa un poco en eso y te daras cuenta de porque Java no acaparo con TODO el mercado de las aplicaciones WEB, y porque estas no resultan lo optimas que podrian resultar.... Te explicaras tambien porque los EJB's no son la unica, ni la mas popular solucion a un problema.... y finalmente, si es que te desembelezas un poco del JDO, te daras cuenta tambien de porque JDO no sera lo que tu esperas y deseas que sea... |
