sábado octubre 07, 2006
Spring si o no? El tema de Spring y frameworks similares siempre parece que trae
polémica. Me apetecía poner un reply a la noticia:
http://www.javahispano.org/news.item.action?id=1036958573, pero como al
final se me hacía un poco largo y, como llevo tanto tiempo sin
contribuir a este blog, pues ahí van mis "dos centimos" al respecto del
tema:
Una aplicacion "profesional" no es algo simple ni sencillo. ¿Por
que nos echa para atrás una tecnologia "complicada"?, Coger cualquier
cosa que tengais a mano (un boligrafo por ejemplo) y abridlo, vereis la
de piezas que tiene y coño: es un puñetero boli!! ¿Alguien sabe la
película que se montan los ingenieros de coches para poner en el
salpicadero un medidor de la gasolina? con lo facil que es poner un
agujerito en el deposito y meter una varilla como con el aceite!!
La informatica es compleja, los programas son "maquinas" muy potentes y
por lo tanto muy complejas y es necesario tener un monton de sistemas,
capas, componentes que tienen que interoperar. Los programadores
tenemos que especializarnos (o ser muy listos). No vale deshechar las
soluciones "complicadas" porque nos cuesta tiempo aprenderlas.
Cierto
que Spring mete mas complejidad a una aplicación, pues a lo
mejor sí, pero es una complejidad controlada. Yo se Spring, y se que si
cojo una aplicacion que utilice Spring, saco el Spring IDE y con los
grafos de beans enseguida me puedo figurar como es mas o menos la
aplicación (su estructura, arquitectura, etc). Ahora bien, si es
una "sencilla" aplicación hecha artesanalmente, ¿por donde empiezo a
mirar? vete tu a saber.
Todo el día llorando porque queremos que la informática sea considerada
como una ingeniería como las demás y luego decimos que es "demasiado
compleja". Pues claro joder, por eso es una ingeniería, por eso la
carpintería no es ingeniería, porque un tablón es un tablón y es mas
simple que un idem. ¿Sabeis la pila de tesis doctorales que hay sobre
tornillos? Tornillos!! un trozo de metal con una espiral! Y hay
empresas que viven solo de diseñarlos!! Y algien dice: "Yo paso de la
norma DIM de tornillos porque total, para pegar un par de piezas de
metal leerme ese tocho..." o "Los tornillos de roscachapa del 12 son
una putamierda porque los fabrica una multinacional corrupta, yo es que
soy de los de estrella de toda la vida porque son mas
humanitarios y progresistas, así que en esta obra yo quiero poner
tornillos de estrella del 5", pues NO.
En otras ingenierías, el que trabaja el hormigón se dedica al hormigón
y el que trabaja el acero se dedica al acero y el que se dedica al
hormigon no dice que el acero es una porquería porque el calculo de
resistencias es demasiado complejo, cuando con un buen muro de hormigón
se arregla todo y el encofrado es mas sencillo.
En fin, esta es mi opinión, aunque no se si mi explicación ha resultado un pelin compleja...
lunes marzo 13, 2006
XML no muerde Leyendo los comentarios al
post de mi colega
David sobre Spring 2.0, me he
dado cuenta de que existe gente, programadores, con cierta "manía" a
los ficheros XML.
Esta gente suele hablar de "programar en XML" y es que, sencillamente,
no es cierto. No se trata de programar en XML, sino de configurar
determinadas librerías (o componentes), utilizando XML.
¿No es mas cómodo decicar, en la medida de lo posible, el código Java a
implementar la lógica de la aplicación sin meter por medio código de
configuración (o de inicialización o lo que sea) de las librerías que
se utilizan?
Si cada librería tiene sus propios ficheros XML, con sus DTDs, donde se
puede configurar todo, ¿qué necesidad hay de mezclar nuestro código con llamadas a APIs de terceras partes, sujetas a cambios de versiones, actualizaciones, etc?.
En mi opinión, es mucho más cómoda la aproximación de Struts, con su
fichero struts-config.xml, donde están mapeadas todas las URLs de la
aplicación, su navegación y los objetos (Actions) que van a ejecutar la
lógica, que la aproximación de Servlets, donde cada Servlet se encarga
de todo: navegación, lógica, etc. y donde no puedes disponer, en un
punto concreto de toda la configuración de navegación de la aplicación.
La ventaja de herramientas como Spring es que te permiten aislar casi por completo tu código de implementaciones concretas de las librerías que estás utilizando. Sinceramente, el precio de tener que escribir XML en lugar de Java no me parece excesivo, solamente es una mera cuestión de sintaxis.
un saludo
miércoles febrero 15, 2006
Continua la controversia con Spring Hace no mucho tiempo, un tal Bob Lee, publicó un post en el que exponía
los motivos por los que no le gusta el contenedor Spring. Como no, el
que busca polémica la encuentra y ya empiezan a aparecer las primeras
respuestas (aparte de la de un
servidor es este mismo blog). Ahora es Keith Donald (del equipo de Spring Web Flow) quien, en su
blog, contesta a las preguntas que se plantea Bob.
lunes febrero 06, 2006
A Crazy Bob no le gusta Spring Lo dicho, a Bob Lee, también conocido como Crazy Bob por su blog no le gusta Spring. En su post del 29 de Enero, titulado "
I don't get Spring" argurmenta los motivos por los cuales no le convence el framework Spring. Entre ellos cita:
- No encuentra ninguna razón convincente para definir las dependencias en ficheros XML.
- No se pueden validar las dependencias en tiempo de compilación.
- Alega que uno de los motivos para utilizar Spring: la
definición de dependencias sin necesidad de tocar el código, es falsa,
ya que considera los ficheros XML como código fuente de la aplicación.
- Spring obliga a duplicar identificadores de objetos: uno para el bean y otro interno, para la aplicación.
- Dice que los nombres de beans de Spring son muy largos.
- La creación de objetos es muy pesada
- No soporta genericos (JDK 1.5)
- Autowiring es inservible. Alega que no lo usa nadie.
- Spring maneja mal los Scopes de los beans: session, request, etc.
Está claro que Spring tiene sus pros y sus contras, como todo... Bob
puede que en algunas tenga razón, aunque en otras se equivoca. Por
ejemplo, yo si que encuentro motivos para definir las dependencias en
ficheros XML: Basta con ver los ficheros XML de Spring como una especie
de "placa base virtual" en la que, de forma equivalente a las placas
base hardware, es posible "pinchar" componentes (en unas son beans, en
otras tarjetas PCI, que mas da?).
A mi, personalmente, esto me parece una ventaja. Al igual que
cuando cojo un PC, para saber lo que tiene lo abro y miro que tarjetas
están pichadas en la plaza, para saber que tiene dentro una aplicación
con Spring, me basta con abrir el fichero/s XML de beans (siempre y
cuando el PC y la aplicación estén bien diseñados).
jueves febrero 02, 2006
Nuevo articulo: Ajax con DWR Me acaban de comunicar que ya está colgado en el portal (en la zona de
tutoriales, creo) el artículo: "Ajax en aplicaciones web con DWR",
escrito por un servidor. Basicamente, este artículo es un pequeño
tutorial introductorio tanto a la tecnología Ajax (muy por encima) como
a la librería DWR (que es muy sencilla y fácil de usar, pero todavía,
al menos cuando escribí el tutorial, estaba un pelin "beta").
Espero que os sea de utilidad y/o de interés.
P.S. El artículo lo podeis encontrar en
http://www.javahispano.org/download.download.action?type=tutorials&id=65
