5 razones para no utilizar Spring

30-07-2007 Raul Vicente

Hace tiempo Luis me envío este artículo y la verdad es que me dejó bastante mal ya que soy un fiel defensor de Spring, pero por otro lado me atrajo ya que es de los pocos que se atrevía a criticar a Spring. Lo tenía en el tintero ya que el inglés utilizado me ha resultado bastante complicado de entender.

El autor da 5 razones para no utilizar Spring:

1. La primera dice que la configuración de Spring está inflada y que si se tienen 100 acciones que trabajan con 100 servicios hace falta configurar cada uno de ellos.
2. Es una crítica a los archivos XML de configuración en sí mismos.
3. Perdida de las ventajas del tipado fuerte, ya que al injectar objetos los fallos sólo pueden dectarse en tiempo de ejecución.
4. El container de Spring no es ligero.
5. Spring promete un software poco acoplado, pero en realidad (según la opinión del autor) , no se preocupa mucho por ello y cree que una vez introducido en la aplicación ésta no puede vivir sin él.

Mi opinión al respecto de estas cuestiones es la siguiente:

1. Es verdad que la configuración de Spring es un poco inflada, pero si se utiliza un archivo XML de configuración siempre vamos a tener este problema. El de Spring, en concreto, no es de los peores. Yo abogo por utilizar en Java Conventions como Ruby on Rails, pero todavía no hay ningún framework que ofrezca inyección de dependencias por Conventions.De paso también contesto al punto 2.
2. Es verdad que no se puede evaluar si un objeto ha sido bien inyectado, más que en tiempo de ejecución, pero hoy por hoy no hay otra forma de inyectar objetos y Spring proporciona otra serie de ventajas que tambíen tienen que ver con la inyección de dependencias muy interesantes como las plantillas para los frameworks ORM u otras plantillas para otros servicios, yo creo que merece la pena pagar el precio.
3. Tiene razón que el container de Spring no es ligero, pero Spring está pensado para ser utilizado en aplicaciones en las que te lo puedas permitir, no tiene sentido utilizar Spring en una aplicación de tiempo real o en una aplicación para un móvil.
4. En cuanto a lo de que no sea desacoplado no estoy de acuerdo, ya si Spring obliga a programar contra Interfaces, si un día se decide no utilizar Spring basta con reimplementar esas interfaces y listo. Por otro, lado Spring no tiene los problemas que tenían los EJB ya que sólo eran ejecutables dentro del Container de EJB, Spring se puede ejecutar dentro de un Container Web o fuera de él en una aplicación Swing normal y corriente. Si se refiere a la implentación de las interfaces claro que queda ligada a Spring, ya que no se puede implementar algo con un framework sin que quede ligado a él, pero me parece una solución mucho mejor a EJB 2.0. El grado de desacoplamiento me parece bueno.

Estas son mis opiniones, pero no tengo tanto bagaje en la informática como para hablar ex cathedra, así que, me gustaría conocer que pensaís vosotros.