Tema: Jdo
Ver Mensaje Individual
  #6 (permalink)  
Antiguo 02/09/2003, 15:56
Avatar de java
java
 
Fecha de Ingreso: junio-2002
Mensajes: 95
Antigüedad: 22 años
Puntos: 1
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...