Los frameworks han llegado a tener una gran popularidad. Generalmente hablando, esto es una cosa buena. Hay muchos frameworks por ahí que son libres, potentes y útiles.
Sin embargo, los frameworks no son una arquitectura aunque algunos intenten serlo.
Autores de frameworks
La mayoría de los autores de framewoks ofrecen su trabajo libre porque ellos quieren ser útiles a la comunidad. Ellos quiero dar de vuelta. Esto es encomiable. Sin embargo, a pesar de sus motivos, aquellos autores no tienen tus intereses en el corazón. Ellos no pueden dado que ellos no saben de ti ni de tus problemas.Los autores de frameworks saben de sus problemas y los problemas de sus trabajadores y amigos. Ellos escriben sus frameworks para resolver sus problemas, no los tuyos.
Por supuesto, tus problemas probablemente se superpondran con otros de sus problemas. Si no fuera el caso, los frameworks no serían tan populares. En la medida que exista dicha superposición los marcos pueden ser muy útiles.
Matrimonio asimétrico
La relación entre tú y el framework es extraordinariamente asimétrica. Tú debes tener un gran compromiso con el framework pero el autor del mismo no sabe nada de ti en absoluto.Si se piensa sobre este punto cuidadosamente cuando se usa un framework hay que leer toda la documentación que el autor provee. En esta documentación el autor aconseja cómo integrar tu software con el framework. El autor te recomienda como derivas de las clase bases del framework e importes las facilidades del framework en tus objetos de negocio. El autor te invita a acoplar tu aplicación al framework los más estrechamente posible.
Para el autor del framework, el acoplamiento a su framework no es un riesgo. El autor quiero que te acoples al framework, porque una vez que estás acoplado es muy complicado desacoplarse. Nada se siente más valioso para un autor de framework que un grupo de usuarios dispuestos a derivar inextricablemente de las clases base del autor.
En efecto, el autor te está preguntando sobre con casarte con el framework pero esto es un matrimonio de una dirección. Tú serás el que tome todos los riesgos mientras que el autor del framework no se compromete a nada.
El riesgo
Los riesgos a considerar son:
·
A menudo la arquitectura del framework no es limpia. Los
frameworks tienden a violar la regla de la dependencia. Ellos tratarán de que
heredes código en tus objetos de negocio, en tus entidades. Ellos quieren que
sus frameworks estén acoplados al círculo más interno. Una vez hecho, este
framework no se puede cambiar. El anillo de boda estará en tu mano.
·
El framework te puede ayudar en algunas características en una
fase temprana del desarrollo. Sin embargo, cuando el proyecto madura, este
puede superar las facilidades del framework. Si llevas puesto el anillo de boda
te encontrarás con que el framework peleará contra ti a medida que el tiempo
pasa.
·
El framework puede evolucionar en una dirección que tú no
encuentras útil. Podrías encontrarte en la situación de tener que actualizar un
framework a una nueva versión la cual no te ayuda. Podrías incluso encontrarte
en la situación en la que algunas funcionalidades están obsoletas y han
desaparecido del framework.
·
Un nuevo y mejor framework podría aparecer en la escena y querrías
hacer uso de él.
La solución
¿Cuál es la solución? Está claro, no casarse con el framework.Se puede usar un framework pero no acoplarse a él. Hay que tratara el framework como un detalle que pertenece a un círculo externo de la arquitectura. No le permitas entrar en los círculos internos.
No permitas que tus clases deriven de los objetos del framework. Deriva proxies en vez y guarda estos proxies en componentes que a su vez sean plugins a las reglas de negocio.
Hay que integrar los frameworks en componentes que se conectan al núcleo de tu código siguiendo la regla de la dependencia.
Conclusión
Cuando te enfrentas con un framework trata de no casarte con él. Mantén framework detrás del límite arquitectónico durante el mayor tiempo posible.
