jueves, 23 de agosto de 2007

La construcción de los Helpers

Derivado del desarrollo de Operación PyME y un poco de sentido común aparece la tarea de construir un framework para construir más rápidamente y fácilmente la aplicación.

Se ha vuelto un concepto casi obligado el utilizar un framework de objetos de negocio pero ¿qué entendemos por esto? Un conjunto de clases que permiten modelar los objetos de un dominio y nos permitan olvidarnos de las tareas mundanas. La idea de fondo es utilizar la mayor parte de nuestra energía solucionando problemas de negocio y la menos posible en los problemas de tecnología.

Así han aparecido en el medio infinidad de frameworks con este objetivo, en todos los lenguajes y en todas las plataformas. Hasta parece que ya se ha llegado a un punto de saturación para estos proyectos. Sin embargo siguen apareciendo.

No existe el framework perfecto, como tampoco el lenguaje perfecto ni la plataforma perfecta. Y siguiendo nuestro inevitable anhelo de perfección vamos creando más proyectos tratando de solventar los errores que encontramos en otros.

No existe una metodología perfecta para construir un framework, generalmente la construcción es influenciada por el tema de moda: aspectos, programación orientada a objetos, inyección de dependencias, objetos auto-suficientes. Algunas empresas han publicado documentos para describir como han concebido y construido los frameworks que ofrecen. Entre estas últimas aparece notoriamente Microsoft.

Después de lanzar al mercado la tecnología .NET, Microsoft ha batallado duramente para posicionarla como una tecnología empresarial (cualquiera que sea su significado). Parte de esos esfuerzos ha sido el desarrollo de bibliotecas de componentes que faciliten el desarrollo de aplicaciones. El esfuerzo inicial dio como resultados los elementos que se conocieron como Application Blocks.

Estos eran conjuntos de clases con un objetivo delimitado. Lo más interesante fue que las construyeron a partir de un análisis que compartieron en forma de guías. En estos documentos exponen los elementos que se consideraron durante el diseño describiendo detalladamente los escenarios y la manera de aplicar la tecnología .NET para construir estas bibliotecas.

Estas bibliotecas fueron rápidamente adoptadas por la comunidad de desarrolladores quienes además fueron enriqueciendo con sus experiencias propias la funcionalidad de las clases incluidas e incluso se combinaron en un nuevo producto que se conoce como Enterprise Library. Sin embargo, tras la aparición del proyecto Mono, que permite la ejecución de programas desarrollados con .NET en plataformas no Windows, se incluyó en la licencia una cláusula que impide la ejecución de los Application Blocks en sistemas operativos distintos a los construidos por Microsoft.

Así que ahora, a pesar de ser elementos tan útiles, los Application Blocks no pueden ser utilizados en Linux o Mac OSX. Existen en el mundo del código abierto cada vez más proyectos basados en .NET y algunos de ellos pudieran resolver los mismos escenarios que se presentan en el diseño de las bibliotecas de Microsoft el ejemplo de inicio es log4net, una biblioteca de clases para registrar entradas en diferentes destinos que forma parte del proyecto Logging Services de la Fundación Apache.

Y también existen otros proyectos que ofrecen alternativas para los otros Application Blocks existentes sin embargo la principal ventaja de la oferta de Microsoft es la unificación que han conseguido y que en los proyectos de software libre se encuentran dispersos e inmersos en otros proyectos y una implementación sencilla, directa y única simplemente no existe.

Así que esta iniciativa (si, una más) es la de tener en un solo conjunto esta funcionalidad partiendo en primer lugar de proyectos ya existentes, como log4net, mostrando como es que se cumplen los escenarios descritos en la documentación de Microsoft y construyendo los elementos necesarios retomando código o creando nuevo para satisfacer las necesidades planteadas por las guías de referencia.

Y si no fuera suficiente... habrá más sobre el tema.

Finito.

1 comentario:

javiercortesl dijo...

Reforzando el comentario de Martin, no hay que perder de vista que el ORIGEN en la mayoria de los Frameworks viene de la solucion de un problema o una necesidad, en algunos casos el origen es aplicar muchos patrones de diseño. Analizando el mundo de java por ejemplo: Hibernate - resuelve una necesidad de persistencia, Spring IoC - resuelve el problema de las dependencias entre objetos, Struts MVC - separa la capa de vista de la capa del modelo.. Es interesante ver que salen y salen frameworks que resuelven casi las mismas necesidades (Struts vs Spring MVC, Hibernate vs Ibatis, etc etc), pero como comentas, quiza no hay framework bueno o malo, mas bien hay frameworks que corrigen algun defecto del otro, o que tienen alguna otra bondad..