31/10/2008
10/11/2008
Debido al anuncio de hace unos días sobre el nuevo manejo de las versiones de Spring que -básicamente- indica que después de los 3 primeros meses de la publicación de una versión mayor de Spring, sólo se publicarán versiones de mantenimiento para los clientes de SpringSource que paguen una subscripción, mientras que las correcciones y nuevas características incluidas en dichas versiones no se publicarán al público en general, sino que simplemente se subirán al repositorio de código sin tags.
Como ya se discutió previamente aquí, el inconveniente de este movimiento es que aquellos que necesiten de estas correcciones, se tendrán que descargar el código fuente y compilarlo para generar sus propias versiones de mantenimiento. Esto puede llevar a que el manejo de dependencias de un proyecto se "rompa" al usar no una versión oficial, sino versiones personalizadas. Debido a esto, Clinton Begin ha anunciado el nacimiento de la comunidad freespring.org que se encargará de construir estas versiones menores de mantenimiento bajo un esquema consistente.
La idea de Clinton es que no existan muchas versiones menores de Spring construidas por muchas fuentes, sino unificar esfuerzos y construir una sola. La página web servirá como lugar de discución y votación para elegir cuáles versiones se irán creando, así como de repositorio maven para distribuir los jars compilados con dichas versiones. Aunque el sitio ya está en línea, todavía no se sabe si la iniciativa tendrá éxito. Mucha suerte a Clinton y sus colegas, esperemos que tenga éxito para que los usuarios de Spring tengamos una fuente segura de donde obtener las versiones con los últimos patches del framework.
Etiquetas: j2se, spring, freespring
Que chapuza!!! Muerte a Spring, se veia venir......eso os pasa por confiar tanto en frameworks de terceros....Tanto Spring, Struts y demás sandeces.....Os recomiendo que vuestros proyectos no se casen nunca con un framework de terceros. Currate tu propio framework que no cuesta tanto.
Creo que ya es hora de aplicar en este mundo tan anarquico del software la máxima del Punk: "Do it Yourself"
Escribes desde un ordenador que te has hecho tu con un browser que te has programado tu?
Lo de programarse uno mismo ciertas cosas no es ninguna tontería. Desde luego, yo no me programaría un browser, ni tampoco una máquina virtual de Java. Pero sí que programo ciertas partes críticas de mis aplicaciones web en las que podría utilizar algún framework ya disponible. En concreto, prefiero implementar el acceso a la base de datos mediante DAOs que se encargan de gestionar el acceso a la base de datos, incluyendo las transacciones; en vez de usar Spring (o un ORM). El motivo por el que prefiero gestionar yo mismo el acceso a la base de datos es que, sinceramente, no confío en Spring. Podéis llamarme paranoico, si queréis, pero el no usar Spring me permite estar a salvo de los bugs de este gigantesco mastodonte (y sí, le he echado un vistazo al código fuente de Spring; precisamente por eso le llamo "mastodonte").
Terminator.
Yo de hecho tampoco me fío de Windows ni de Linux, diplodocus los dos, atestaos de bugs porque tienen más de 300 líneas de código. En cuanto acabe mi sistema operativo, el Ibonux, en el 2050 o así, empezaré a hacer proyectos.
Salu2
Pues yo prefiero confiar en herramientas open source que usamos y mantenemos entre millones de personas. No es tan satisfactorio para el ego pensar que otros pueden saber más de transacciones (por ejemplo) que yo, pero a mi me funciona.
ibon, el exagerar la opinión de otro con el objetivo de ridiculizarla es una de las estrategias típicas de la demagogia. La opinión de Terminator es compartida por mucha gente. Por poner un ejemplo, Dan Berstein, el creador del servidor de correo más seguro del mundo (qmail), no se fiaba de algunas partes de la librería de C y las reescribía.
jejej cierto, en mi caso pues yo si que confio en el trabajo de terceros, no de todos (no me atreveria a usar el Ibonux :-), pero si algun framework tiene tanto tiempo de existir, se usa en un monton de lugares (incluido grandes empresas), tiene un kilion de libros y tutoriales y articulos debe ser por algo, un mastodonte podria ser el resultado de años de investigacion y diseño y mejoramientos y horas de expertos trabajando en enel. Pues un mastodonte puede soportar una carga de trabajo muchisimo mas pesada que un chiguagua.
Lo que yo hago con estos mastodontes como Spring, Hibernate y otros y es vestirlos con un estilo que me guste y que sea para mi mucho mas facil de mantener, es decir, creo una super fina capa de abstraccion sobre ellos en forma de una libreria de utilidades que me permiten domar a estos mastodontes usando cosas mucho mas simples y a mi estilo que las que ellos mismos traen. Obviamente no me pongo a crear mi propio descriptor de XML o mis propias anotaciones porque mi tiempo y energias son mas importantes para la parte de logica de negocios.
Pues yo estoy de acuerdo con Terminator. Yo también uso DAOS sin Spring porque, en realidad, el aprovechar las facilidades transaccionales de Spring no me quitaría mucho trabajo; y al usar DAOS sin Spring, si algo falla, puedo saber seguro que el problema está en mis DAOS, y no en el Spring o en mi utilización de Spring. Vamos, que prefiero no añadir capas y capas a mis aplicaciones, a no ser que las capas merezcan mucho la pena (por ejemplo, sí que uso un action framework cuando me facilita mucho el desarrollo).
Ainchs... que poco sentido del humor... Me ha hecho gracia que se llame a Spring "mastodonte"... beneficios de la edad el poder recordar como Spring hizo que se llamara a los EJB2.1 mastodontes, y como ahora se vuelve a 10 años atrás, programando tus propios JDBC para que sea "ligero". ¿Es el eterno retorno que preconizaba Nietzche? No, que son algunas nuevas generaciones que vuelven a creerse que sus mayores están equivocados y no han inventado nada a derechas.
El tiempo, la experiencia y sobre todo las bofetadas de los proyectos cambian el propio ser. Y os veréis dentro de unos años manteniendo esta misma discusión en un foro de internet. Y comprenderéis que estáis envejeciendo.
Salu2
PD: ¿Y porque fiarse de los drivers JDBC? ¿Porque no hacerlos uno mismo? ¿Y porque fiarse del código de Terminator y no hacerlo uno mismo? Eternos ciclos encerrados en bucles infinitos.
Yo prefiero ser lo más estandard posible. Para aplicativos web, parto de las API's básicas Sevlet y JSP y me creo mi propio MVC. Si utilizo alguna libreria extra que sea una implementación de una JSR de SUN como JSTL o JPA.
Un ejemplo, me niego a utilizar log4java cuando ahora desde la versión 1.5 del JDK ya existe java.util.logging.
Será una broma, ¿no? En cualquier caso alguien que no sabe ver las bondades de frameworks como Struts, Log4j, Spring, etc. no merece mayor atención. Porque yo si que he sufrido/usado muchos frameworks 'propios' y sus brillantes diseños (sarcasmo) y entre si falla el código de Spring o el de mi compañero/yo mismo, apuesto que lo segundo. Muy contento estoy precisamente de haber sustituido nuestro framework 'propio' por Spring. Vamos que entre Terminator Framework y Spring, pues no hay color.
Y volviendo al verdadero tema de la noticia. Yo nunca he participado en un proyecto open-source, me declaro chupoptero, pero algo de CVS sí que se. Entonces vale que no tengamos el tag V3_0_4 (pej), pero si tendremos la fecha de la versión. No deberia ser muy traumatico hacer un checkout usando la fecha de release en vez del tag de release. Según tengo entendido en los proyectos open-source no es que se hagan commits todos los dias y los de los desarrolladores no habituales hacen sus colaboraciones en forma de patches, por lo que no deberia haber mucho conflicto.
No se si es que nadie ha pensando en esto nunca o que estoy sumando 2+2 = 5. Que todo puede ser porque a mi la mente no me da para hacerme mis frameworks propios...
"El tiempo, la experiencia y sobre todo las bofetadas de los proyectos cambian el propio ser. Y os veréis dentro de unos años manteniendo esta misma discusión en un foro de internet. Y comprenderéis que estáis envejeciendo."
Amén!
:)
Saludos Ibon!!!
Vamos que entre Terminator Framework y Spring, pues no hay color.
jcesarperez:
Por favor, no tergiverses mis palabras. Yo no he programado ningún framework ni pretendo hacerlo. He dicho que prefiero programar por mí mismo ciertas partes que considero críticas en vez de usar algún framework para estas partes críticas. Y he puesto un ejemplo concreto: el acceso mediante DAOs "clásicos", sin utilizar la parte transaccional de Spring. Pero no he dicho que no utilice frameworks. De hecho, en la última aplicación web que he desarrollado he utilizado struts2, pero para el acceso a la base de datos he utilizado DAOs clásicos, en vez de utilizar DAOs basados en el jdbctemplate de Spring, por ejemplo. No creo que consideres poco adecuado el utilizar DAOs "clásicos", ¿verdad? De hecho, hay mucha gente que está volviendo a los DAOs "clásicos" para conseguir una mayor eficiencia y "precisión" en el acceso a la base de datos.
Terminator.
"Las generalizaciones son el refugio de las mentes simples"
O sea, ni si, ni no, ni todo lo contrario. Hay cosas que empezaron como alternativas simples y ahora ya no lo son, por que han crecido y evolucionado para "ampliar su funcionalidad" y en algunos casos han acabado siendo igual de complejo de lo que vinieron a sustituir, aunque normalmente por otro lado y con otras pegas.
Si, las frases lapidarias quedan muy bonitas, pero algo como esto "alguien que no sabe ver las bondades de frameworks como Struts, Log4j, Spring, etc. no merece mayor atención" no merece mayor atención. Struts ha sido declarado por sus propios creadores como pesado y obsoleto y hay bastante gente que no lo usa y"sorpresa sorpresa" a veces sus aplicaciones hasta funcionan. Hay otros frameworks alternativos a Log4j y el propio creados de la librería trabaja ahora en una alternativa bastante diferente por que le parecía más sencillo que evolucionarlo que hay... si lo dice él...
Así que si me sirven: los uso, si no me sirven: no los uso, por muy populares que sean. Y si no hay nada que me sirva y tengo que hacerlo yo, pues ya me preocupo de que lo pueda mantener y tenga mis razones para no usar algo imperfecto pero que mantenga otra gente, que siempre viene bien. Lo de que "es bueno si es popular y lo usa mucha gente" es una falacia en la que nos gusta refugiarnos para no ser "tontos solitarios" y poderlo ser en compañía :). Si fuera así, el Windows sería el mejor S.O. y el explorer lo ultimo en navegadores, el Tomcat 3.0 y los JSP+EJB1.1 fueron la leche de populares en su momento y eran dos m... pinchadas en sendos palos.
Que manía con que todo el mundo use lo mismo... ni que todos hicieramos el mismo tipo de apliaciones en el mismo entorno con los mismos medios.... en fin.
Volviendo al tema... no se como irá la iniciativa. Sin seguir muy de cerca el proyecto y sus cambios y sin tener "información privilegiada", no se yo si conseguiran que sus builds sean tan estables como para que la gente confíe en ellos... y sobre todo que colabore para conseguirlo. Por que pedir es muy facil, arrimar el hombro suele ser menos popular :).
ge que te desvías ;-). En mi caso el motivo de chanza, broma y chasquarrillo es: "Podéis llamarme paranoico, si queréis, pero el no usar Spring me permite estar a salvo de los bugs de este gigantesco mastodonte". Me parece que fué lo mismo que dijo el programador del Titanic :-D
De hecho a mi nunca me ha hecho falta Spring, pero confiar más en el propio código que en el creado por 47 programadores (http://www.ohloh.net/projects/spring) pues es ................. Otra cosa es necesitar sus funcionalidades o no, o que en un proyecto tenga sentido o no, o la frameworktitis. Pero que la motivación para reinventar la rueda sea "el no fiarse" a mi me recuerda mis inicios... cuando mi código iba a cambiar el mundo :-D
Salu2
confiar más en el propio código que en el creado por 47 programadores [...]
Pues yo sí que confío más en un par de inserts metidos en un try catch finally (con JDBC a pelo) que en eses mismos inserts gestionados por el motor transaccional de Spring, por muchos programadores que tenga.
Entiendo lo que dices y estoy de acuerdo en la parte de fiarse o no. Pero tambien tiene su lado contrario y con lo de "fiarse con que lo hagan los demas" he visto mas chamuscados que en El coloso en llamas :).
Y esa frase tiene su parte de razon, cuando el bug que te afecta a ti le importa un rabano a 46 de esos programadores por que tienen otros intereses y el 47 está de vacaciones. Por eso hay que escoger con cuidado que se echa uno a la espalda y que "delega", y en caso de delegar hasta que punto te vas a "casar" con un proyecto y que riesgo tiene.
Si necesitas un Notepad, da igual que el Word lo hagan 500 o 600 tíos, a lo mejor tu te puedes hacer lo que necesitas y funciona mejor para lo que lo usas que el super Word por que luego a lo mejor los 600 tíos estan dedicandose a X cuando tú sólo usas un 1% que no es X y justamente tiene un bug del que pasan.
Pero como ya hemos dicho, no es generalizable. Ni es factible hacerselo todo en ensamblador, por si los compiladores fallan :), ni es recomendable irse con el primero que pilles por ser popular, grande y no tener que mantenerlo tú. Es la parte de la informática que no es meramente programar...y tiene su gracia ;).
Creo yo que tengo el mismo derecho a crear mi propio framework como lo hizo la gente de Struts o Spring. A mi me podeis llamar loco, pero ¿a ellos no?
En este país (España) donde el aire emprendedor brilla por su ausencia se nota incluso en el desarrollo del software. Nos limitamos a ensamblar nuestras aplicaciones a partir de otros frameworks de terceros y que sean otros quien los creen por nosotros.
Cierto, que muchos no teneis tiempo ni ganas debido a las directrices de las empresas en las que trabajais, que lógicamente buscan la productividad y no se les pasa por la cabeza reinventar la rueda.
Lo que está claro, que Java se está volviendo una locura. En las entrevistas de trabajo ya no te piden si sabes Java o no, te piden directamente si sabes Strus, Spring, Hibernate, etc.....Les importa un bledo si tienes claro los conceptos de herencia, interfaces, Servlet's, etc....
Me gustaría volver a los 80's, cuando acudia a la librería y me compraba "La Biblia del Pascal" y allí estaba todo lo que debia aprender del lenguaje.....Todo era más facil, cada página una instrucción del lenguaje, y luego a dejar volar mi imaginación programando libremente.....me creaba mis librerías y punto, nadie me cuestionaba ni decía que estaba loco....
Esto, chicos, se muere, el desarrollo del software se está complicando demasiado, hay exceso de frameworks y soluciones y al final el exceso de información te vuelve loco, no es positivo.
Yo apuesto por que SUN marque las directrices a partir de sus JSR's, tal y como ha hecho con JPA. Y luego cada uno es libre de elegir al fabricante de turno que implemente JPA. Si desaparece el fabricante, pues a otro, pues JPA es una especificación no una implementación. Que un día desaparece Spring, pues a joderse, pues ya lo sabias cuando lo elegistes: "no es una especificación."
JoseGM.
Desde luego también podemos irnos más atrás... A ver, suelo ser muy crítico con la frameworktitis, pero en este caso os estáis pasando tres pueblos. CREAR TUS PROPIOS DAO'S o USAR LA API JDBC DIRECTAMENTE no es crear un framework precisamente. Y eso es lo que llama a la broma.
Quiero pensar y pienso que si se ha creado un framework es porque existía una necesidad. Vale, tal vez no hayas trabajado nunca en un proyecto que haya tenido necesidad de ese framework, pero chavales, de ahí a decir que se prefieren inserts a pelo de JDBC frente a una solución que te ayuda a implementar hasta transacciones de aplicación (¿Cómo las implementa el anónimo?) va un trecho. Sudores fríos me entran si alguna vez tuviera que lidiar con una aplicación de banca electrónica en el que algún iluminado haya implementado todo en base a JDBC a pelo.
Y respecto a esas peticiones de ofertas, pues mira, prefiero que ahora pidan programadores que conozcan esos frameworks, porque las limitaciones impuestas por esos frameworks protegen a la empresa del programador "iluminado" yo me lo guiso-yo me lo como, que llega al 30% de funcionalidades con su pericia y buen hacer, pero que abandona la empresa a los primeros problemas que su código empieza a no poder resolver. Y el próximo programador es el que pringa...
No discuto vuestras habilidades, pero en el tiempo que llevo programando (en España) aún no me he encontrado con el genio que además de resolver los problemas, crea código claro y mantenible, de una forma mucho más eficiente que determinados frameworks en los que participan más de dos ojos y más de un cerebro. Lo siento, el tiempo de las "divas" acabó. Y menos mal.
Salu2
Hasta que Spring , Struts o similares no sean normas ISO no los utilizaré.
De momento sigo con mi propio framework y las implementaciones de las JSR's de SUN.
O estandarizamos el software de manera correcta o no hagamos lo mismo que ha pasado con el formato microsoft word, que la gente se cree que es un estandar cuando no lo es, únicamente es que está extendido masivamente.....
Mientras el desarrollo del software no se regule, yo seguiré siendo un artista del software no un ingeniero del software.......
Pues nada artista, espero no tener que lidiar con tu framework nunca.
Salu2
Nos estamos desviando del tema. Pero a mi esto de criticar a la frameworktitis me fascina.
Os contaré un caso real. La empresa de seguros Zurich construyó algunos de sus aplicativos internos en base a Struts. Los consultores de Accenture les vendieron la moto y crearon una arquitectura que consistia en crear más capas por encima de Struts. A día de hoy, asesorados por los mismos, van a cambiar a Spring, ya que ahora es lo más 'hype'. Y mañana Dios sabrá.....
Esto es un negocio y a las consultoras les interesa que aparezcan y desaparezcan frameworks para convencer a sus clientes que han de actualizarse, que están anticuados....que todo el mundo ahora utiliza Spring, que es como el SAP, que viste y da prestigio decir en una cena de negocios: "Nosotros utilizamos SAP!!!".
Jo greeneyed me estoy empezando a preocupar, estoy empezando a coincidir demasiado contigo XD
Yo creo que estáis metiendo demasiada caña a JoseGM, él simplemente defiende que prefiere usar JDBC a pelo que usar las utilidades JDBC de Spring, pero es que las utilidades de JDBC de Spring (el JdbcTemplate) no es que sean la solución a tu vida, es una fina capa de abstracción sobre JDBC que yo creo que no ha cambiado la vida de nadie y que su uso supone una nueva API, otra forma de hacer las cosas y el ceder algo de control.
Está claro que no se puede reinventar la rueda constantemente (salvo en mi caso pero es que ese es mi lugar en este mundillo) y que hay que estar algo abierto a las novedades que pretenden mejorar tu productividad y la calidad de tu código (no es lo mismo que abierto de piernas a cualquiera) .
Yo a veces oigo que se usa Spring para persistencia porque automáticamente te inicia una transacción cuando llamas a un método declarado como "transaccional" y no puedo evitar pensar "¿pero es que no sabes abrirla tú?" o "¿pero es que no sabes cual la demarcación de tus transacciones?", no digo que Spring no ofrezca mucho más, lo que hay que plantearse es si merece la pena contratar un criado para que sólo vaya a por el pan.
A veces pequeños problemas se resuelven con una sencilla clase base/interface de tu cosecha, en mi opinión los microframeworks son parte de la vida cotidiana de un buen programador, la reutilización en general, si nuestro código no tiene partes que dan servicios a otras, no tiene herencias, polimorfismos esas cosas de toda la vida a mi personalmente me da muy mala opinión del programador por muy larga que tenga la lista de los frameworks que usa. La premisa es que cualquier programa en cierto modo es un "framework" de propósito específico.
Yo creo que el debate debería estar entre JDBC a pelo vs JPA/Hibernate o debate JSP a pelo vs framework web X, pero el debate entre JDBC a pelo y JdbcTemplate me parece una pérdida de tiempo.
Los debates JDBC a pelo vs JPA o JSP a pelo vs framework web X sí que son más interesantes porque ahí el planteamiento de JoseGM tiene mucho más valor pero también es mucho más arriesgado:
¿merece la pena adaptarse a una forma de trabajar impuesta, introduciendo limitaciones y pérdida de control por el uso de un framework concreto a cambio de ganar productividad y quizás robustez?
Esa es la gran pregunta y la respuesta no es tan clara.
"¿merece la pena adaptarse a una forma de trabajar impuesta, introduciendo limitaciones y pérdida de control por el uso de un framework concreto a cambio de ganar productividad y quizás robustez?"
a) Si eres una máquina programando no. Y cuando digo máquina quiero decir: "puedes programar en el tiempo disponible de un proyecto todas las características útiles para el proyecto que te ofrece el framework X y tu código es mantenible"
b) No he conocido a ningún máquina según la definición a.
Generalmente, y coincido con jcesarperez, cada vez que oigo "he creado mi propio framework que no ha visto y probado nadie más que yo y los sufridos programadores que han entrado en esta empresa española"... me echo a temblar.
Salu2
@ibon: "aún no me he encontrado con el genio que además de resolver los problemas, crea código claro y mantenible, de una forma mucho más eficiente que determinados frameworks en los que participan más de dos ojos y más de un cerebro"
Hacer código claro y mantenible no es muy dificil. Es relativamente facil siempre y cuando no tengas que hacer "mastodontes". Cuando uno inicialmente se hace un framework suele ser con funcionalidades sencillas, no pretende hacer un "Spring" o "Hibernate". Así que en ese caso tiene sentido un framework propio. El problema es cuando el framework en casa empieza a evolucionar e intenta tener las mismas funciones que "Spring" o "Hibernate", entonces si tienes razón que no creo que sea tan facil hacer bien las cosas y lo mejor es ir pensado en usar un framework de terceros.
@jmarranz: "el debate entre JDBC a pelo y JdbcTemplate me parece una pérdida de tiempo."
Estoy totalmente de acuerdo contigo.Pero yo voy un poco más. Nunca uso JDBC a pelo. Tengo mi pequeña librería que me evita las Check Exceptions (Las relanzo como RuntimeException) y me simplifica el usar parámetros en la SQLs.Y no pasa nada por hacerme esta librería. ¿Acaso tengo que usar algún mastodonte "cool" para hacer esto?¿No estoy capacitado como informático para poder hacermelo?
Otro ejemplo es el del Log4j que como ya ha comentafo greeneyed, el propio autor ahora tiene un nuevo proyecto: http://www.slf4j.org/nlog4j/.Este tema siempre me ha hecho gracia. ¿Tan dificil hacer un log? Pués depende de los requerimientos que uno tenga. Si siempre vas a querer guardar a disco y tu proyecto es pequeño y con pocos usuarios pués no hace falta Log4j. Si necesitas toda la versatilidad de log4j pués úsalo, pero no se debe criticar a nadie por hacerse sus propios frameworks.
Por último lo que suelo hacer es crearme mis propios interfaces de los frameworks que uso, por ejemplo el Log, JDBC, Transacciones,Reports, etc. Así puedes empezar con una implementación en casa y si las funcionalidades crecen puedes cambiar de implementación y usar un framework de terceros. La idea es parecida al proyecto Simple Logging Facade for Java (SLF4J) pero para todos los servicios que usa una aplicación y así no me caso con nadie.
Saludos
Yo a veces oigo que se usa Spring para persistencia porque automáticamente te inicia una transacción cuando llamas a un método declarado como "transaccional" y no puedo evitar pensar "¿pero es que no sabes abrirla tú?" o "¿pero es que no sabes cual la demarcación de tus transacciones?"
Je, je. Tienes toda la razón del mundo. Yo me he encontrado un caso incluso más exagerado que el que comentas: Un programador que terminó una pequeña aplicación web y me comentó que había usado Spring para el acceso a la base de datos porque "es una maravilla: te gestiona las transacciones y no te tienes que preocupar de nada". Lo curioso es que en el programa sólo había un insert, que no tenía que ejecutarse transaccionalmente con nada más. ¡Cómo está el patio!...
Yo es que me he debido perder algo estos años inmerso en Java ME y Java SE. A ver ¿Spring no era un container "ligero"? Osea ¿no se usaba inyección de dependencias? ¿No podías decir tú lo que querías usar o no en tu proyecto? ¿No había que NO arrancar miles de servicios Java EE? ¿No permitía hacer aplicaciones de cualquier tamaño? Es que por lo que decís esto me recuerda a los gloriosos años de los EJB.
Y me parece que estáis confundiendo usar mal el framework con usarlo, a secas. Pregunta: ¿Una aplicación web, con digamos 100 casos de uso, hecha con servlets a pelo, no os parece una locura? ¿Una aplicación que vaya a ser balanceable en un cluster de servidores hecha con JDBC a pelo, no os parece una locura? Pues para mí son tan locura como crear un blog usando EJB's, todos los módulos de Spring o la madre del cordero. Pero oye, igual la tendencia en el mundo web después de matar a los EJB's, y ahora a los container ligeros sea vover a hacerlo todo uno mismo...o simplemente acabaremos diciéndo eso de "es que las aplicaciones web no deberían ser usadas para eso".
Salu2
Creo que es una cuestión de dimensión en cuanto al tema. No es que haya que hacerselo todo, ni mucho menos, pero tambien es cierto que en muchísimos casos, ni hay 100 casos de uso, ni hay clusters de servidores ni nada parecido.
En cuanto a que Spring sea "ligero" o no.. pues como dicen, depende del prisma con el que lo mires. Para simplemente tener "transacciones demarcadas", cosa que puede que ni necesites realmente como dice el anonimo anterior, pues es peso muerto. Ahora, si lo comparas con tener que hacer otras cosas, pues entonces si es ligero.
¿El NotePad++ es ligero? Hombre, comparado con usar, por ejemplo, el NetBeans/Eclipse para editar simples ficheros de texto, es ligero como una pluma. Ahora, si para mi caso de uso me basta con acceso remoto con vi y usar el NotePad++ me obliga a montar un entorno grafico remoto, permisos para el gestor de ventanas etc. etc. pues me parecerá pesadísimo.
PD: Y para cerrar el circulo, resulta que muchas empresas que se dedican a aplicaciones cuyo rendimiento es crítico y han de controlar hasta el ultimo detalle, en muchos casos optan por el JDBC a pelo precisamente por no poder dejar en manos de terceros detalles donde les va el negocio.
Pero como decían en una discusión que leí hace poco pero no recuerdo donde: ¿cómo decides lo que haces tú y lo que dejas en manos de otros? Pues es la pregunta del millón y la idea general suele ser "depende de lo que sea tu negocio". ¿O acaso vosotros usais sólo librerías de terceros para JME sólo para no tener que mantenerlas y si tienen fallos, pues ala, a cascarla?
No es tan sencillo como "que lo hagan todo los demas", ni "me lo hago todo yo". Además, si todo el mundo hiciera eso no habría ninguna evolución excepto a golpe de vendedores de productos. Y ya vimos lo bien que va eso con JSP+EJB 1.1
Bueno iré por partes.
1) En ningún momento he pretendido faltar a nadie. Simplemente me interesaba mucho más el tema de la noticia (aunque ahora ya no importa mucho) que el debate por ver quien la tiene más larga en el que no voy a entrar.
Tampoco soy ningun evangelista de nada. Él que quiera crearse su Struts, Log4j o Spring Jdbc allá él, si es féliz y le dejan. Yo respeto las rarezas de casi todos pero prefiero usar una solución existente, bien diseñada, que cubre mis necesidades, madura, más que probada, documentada y con gente a la que poder preguntar en caso de duda, que no popular o cool.
Y eso sí, tengo más que comprobado el nivel medio del programador Java y si todos fueramos tan listos como nos creemos los proyectos saldrian como churros, libres de bugs y no ganariamos lo que ganamos en general. ¿O es que todos vivimos una conspiración de los necios?
2) De verdad habeis usado Spring core + Spring jdbc en un proyecto real u os habeis limitado a leer/probar el típico ejemplo del tutorial de turno? Porque cuando hablais de eficiencia y precisión, eso lo consigue la sentencia SQL a ejecutar pero luego queda todo el código de control de transacciones, gestión de la conexión, tratamiento de excepciones, liberación de recursos y peleas con algun comportamiento propio del SGBD+driver JDBC.
No hay que ser un genio para programarlo, vale, pero hay que hacerlo y probarlo. Además que luego se queda ahi, estorbando y distrayendo de los ojos que luego tienen que entender nuestro código. ¿Y si puedo ahorrarmelo? ¿Que serían 20 líneas? En una aplicación típica de intranet con tus ¿20? daos, con ¿8? métodos por dao, nos da 3200 líneas de código que no tengo que escribir y probar.
Luego suma las otras ventajas de usar Spring, como
a) usar inyeccion de dependencias: con unas lineas de XML cambio mi datasource gestionada por el servidor por una independiente que uso desde junit para probar toda mi capa dao. No sólo en el desarrollo inicial, sino en futuros mantenimientos. Tambien me he ahorrado creas todas esas factorias de daos o singletons
b) ya que estoy haciendo tests, uso el test transaccional de Spring que me hace automaticamente un rollback haciendo que mis tests no modifiquen el estado de la bbdd para que sean repetibles.
c) tengo una capa de abstracción para las excepciones independiente de si uso jdbc, hibernate, ibatis, etc.
d) tengo soporte para transacciones distribuidas por si mi app usa varias bbdd.
e) puedo usar AOP para montarme un sistema de log o de auditoria que cubra todos los metodos de todos los dao existentes y futuros sin modificarlos.
¿Qué tu eres capaz de crearte un framework/libreria que haga todo eso? Permite que lo dude, pero aun así y ¿para cuando va a estar porque tus compañeros de equipo están esperando semejante 'mastodonte'? ¿vas a documentarla? ¿vas a contestar dudas? ¿vas a mantenerla? y aparte supongo que los proyectos de turno estarán a tiempo, ¿no?
Yo no, por eso uso Spring :-)
PD: Que curioso que en casi todas las noticias de Spring siempre saltan los mismos que curiosamente no lo han usado nunca en serio. Sin acritud.
jcesarperez: "el código de control de transacciones, gestión de la conexión, tratamiento de excepciones, liberación de recursos y peleas con algun comportamiento propio del SGBD+driver JDBC."
No veo que sea muy dificil de hacer todo eso , de hecho yo lo tengo hecho incluidos los apartados a) y d).
Y respecto a los apartados siguiente:
a) Ya he dicho que no lo veo dificil y no se que tienes contra las factorias y singletos. Ya hubo una discusión aqui en jH sobre eso y no vi tantos problemas.
b)¿Cual es la dificultad de hacer un rollback?
c)Eso no se si será dificil pq no los he usado.
d) Eso no lo hace Srping sino JTA y abstraerte de si usar JDBC o JTA tampoco es dificil.
Para mi es lo más interesente de Spring y eso si que no tengo ni idea de como se hace.
Todo esto lo digo sin saber de Spring pero en base a lo que tu comentas en general no lo veo nada dificil.Además de "mastodonte" tiene poco son casi todo Interfaces que encapsulan llamadas a API que ya hay en Java así que las implementaciones de dichos interfaces que no tienen mucha dificultad.
Lo de que estén esperando tus compañeros no es mucho problema ya que es algo que se hace para un proyecto y debería valer para cualquier otro, así que solo se esperaría en el primero.
Por último está el tema de documentarlo, eso si que se me hace más dificil y en mi caso monté un wiki para ir aciendo documentación.
Saludos.
PD: Que curioso que en casi todas las noticias de Spring siempre saltan los mismos que curiosamente no lo han usado nunca en serio. Sin acritud.
Bueno, si entramos en el terreno personal en vez el de los argumentos, entonces hasta la vista. También sin acritud :).
¿Una aplicación web, con digamos 100 casos de uso, hecha con servlets a pelo, no os parece una locura?
Depende.
Si tengo que hacer una aplicación web típica, con 100 casos de uso, la haría con algún action framework.
Pero si tengo que hacer una aplicación web con 100 casos de uso Y CON LA ESPECIFICACIÓN DE REQUESITOS DEFINITIVA Y TOTALMENTE ESPECIFICADA (valga la redundancia), entonces la haría con servlets, puesto que conseguiría una eficiencia y control muchísimo mayor que con un action framework.
El usar servlets "a pelo" no tiene nada malo, siempre que programes bien, pongas cada cosa en su sitio y no andes metiendo html por todos los lados.
Ebay, por ejemplo, se ha programado con servlets, precisamente para conseguir la máxima eficiencia.
Además, la utilización de CSS te permite separar muy fácilmente el html de los "adornos". Así, para una aplicación, puedes variar mucho el aspecto sin tener que tocar los servlets (y/o JSPs).
¿Una aplicación que vaya a ser balanceable en un cluster de servidores hecha con JDBC a pelo, no os parece una locura?
En esto sí que tengo mucha experiencia porque en mi empresa utilizamos balanceadores y muchos servidores, si bien una única base de datos central:
Cuando, por motivos de eficiencia, tienes que montar un tinglado así (balanceadores y muchos servidores contra una única base de datos central), entonces lo ideal es, precisamente, trabajar con JDBC y SQL a pelo (lógicamente con un buen pool de conexiones y sin andar metiendo SQLs por todos los lados; cada cosa debe estar en su sitio). Porque el punto crítico es el acceso contra la base de datos y es aquí donde debes hilar muy fino para conseguir la máxima eficiencia. En cambio, en los servidores, si tienes problemas de eficiencia, metes más y listo, con lo que te puedes permitir el lujo de usar action frameworks aunque ello suponga que sean un poco más lentos. Pero, desde luego, no te puedes ni plantear usar un ORM ni similares.
Escribe tu comentario