Diego Berrueta

(This is a reprint of the original post)

Animado por los compañeros, he tratado de acabar con una de mis lagunas entre las tecnologías y productos de moda en J2EE. Recientemente he terminado de leer Spring in Action. Tal y como había oido, Spring parece un framework muy bien diseñado, y la IoC le da un aire nuevo a la orientación a objetos, reduciendo el acoplamiento. Una ventaja evidente es que es mucho más fácil escribir pruebas unitarias. Por otro lado, en algún sitio hay que inyectar las dependencias, y la forma que tiene Spring de hacerlo no acaba de convencerme del todo (el fichero XML de Spring rápidamente se "ofusca"). No obstante, mi impresión de Spring es bastante buena.

Curiosamente, el libro no ha satisfecho mis expectativas. La colección "In Action" de Manning suele ser excelente, pero en este caso, los autores pretenden mantener la atención del lector mediante paralelismos que parecen un poco fuera de lugar. Y extrañamente, no resulta difícil encontrar errores de edición (erratas en los listados de código, tablas y figuras incorrectamente referenciadas, etc.). Una nueva edición revisada no estaría de más.

En cuanto a la segunda parte del título de este artículo, de un tiempo a esta parte es cada vez más habitual encontrar tecnologías J2EE que se suman a la corriente de lo "alternativo", y que dicen tratar de evitar la complejidad de los EJBs. Vale, los EJBs no son sencillos, como tampoco lo son los problemas que resuelven. Es evidente que podrían ser más sencillos, y por ahí están comiéndole mucho terreno a J2EE. Pero eso tampoco es un argumento que demuestre nada, y últimamente se oye mucho eso de "pruebe X, que lava más blanco porque los EJBs son muy complicados". En mi opinión, no se debe caer en el error de aplaudir la llegada de una nueva tecnología porque es más fácil de usar que los EJBs (pero quizás no ataca a todos los problemas que atacan éstos). Después de esta reflexión, sigo diciendo que Spring me parece un paso por el buen camino.