Como mencionaba en un articulo anterior, en el cual se pudo notar todo mi descontento con un framework (que hasta la versión 4 era un ejemplo a seguir) y su empeoramiento en las dos ultimas versiones, he de hacer una reflexión sobre 'los frameworks'. OJO, no solo me voy a referir a los de Microsoft, sino a todos los frameworks y apis que últimamente inundan el mundo de la programación.
Los frameworks eran 'paquetes de librerías'
En un inicio, cuando fueron concebidos los primeros framework del mercado, no recibían ese nombre, simplemente eran paquetes de librerías que te descargabas y podías hacer con ellos ciertas funciones de manera mas sencilla. Un ejemplo claro fueron todas las librerías creadas para C/C++ y que hoy en día se siguen utilizando.
Como tales 'paquetes de librerías', tu llegabas a tu proyecto, instalabas las librerías que necesitases y felizmente te olvidabas del resto. Eran fáciles de enlazar y la documentación estaba bastante bien realizada, ademas de que en la mayoría de los casos podías ver el código fuente que añadías a tu aplicación.
Las maquinas virtuales y el lío padre
Fueron dos las maquinas virtuales (por llamarlas de alguna manera) que cambiaron la forma de hacer las cosas. La primera fue Java y su JDK, el cual en un principio diferenciaba bien la parte de la maquina virtual y las librerías que podías usar, o no, en tus desarrollos. Por su parte Microsoft hizo su parte con el inicio del .net Framework.
Pero el problema llego cuando quisimos añadir una nueva capa de complejidad y pensamos que 'paquetes de librerías' no era lo mismo que 'frameworks'. Estos últimos se han diferenciado desde su origen por añadir 'capas de abstracción' que en algunos casos, no controlan los errores adecuadamente y que no son completamente accesibles por el desarrollador. El ejemplo que me viene a la cabeza es Apache Tomcat un famoso servidor que implementa distintos 'frameworks' que te ayudan a crear aplicaciones web en java, hasta ahí la cosa va bien y suena divino.
Uno de los principales problemas de frameworks es que tienden a estar separados de las bases sobre las que se implementan (Entity framework viene a parte de .Net framework y struts viene a parte de Apache Tomcat). Es decir, volvemos a los tiempos del 'es compatible con...' lo cual indica que algún error sale fijo.
El principal problema, como dije anteriormente, es cuando surge un error en el código que estas programando, pongamos el típico ejemplo de un error en la base de datos el cual, debería de propagarse y ser notificado en capas mas cercanas a la lógica del código que estas desarrollando. Bien, seamos mas específicos:
En un sistema en el que uso MySQL + Apache tomcat + struts + hibernate (siendo estos dos últimos frameworks que añado y siendo tomcat 'compatible con' las tecnologías J2EE ).
Me salta un error en la base de datos, el cual se debería de propagar a hibernate y posteriormente hacia struts para notificármelo... El caso es que, después de numerosas capas de abstracción generadas por hibernate y struts, el mensaje que suele llegar es la famosa pantalla de tomcat con franjas azules que te dice 'hay un error', pero no tiene ni idea de que lo causó. La solución a esto suele pasar por implementar decenas de lineas de codigo para redireccionar cada apartado de codigo que pueda fallar, bien a archivos log o al propio log de tomcat...
El caso del EF 5 y 6
En el Entity Framework 5 y 6 lo que vemos es explicable desde el punto de vista de que, cada cierto tiempo microsoft empeora sus tecnologías para después poder ir mejorandolas en un ciclo casi eterno de romper y crear. Hasta el año 2010 vimos como tomaron madurez tecnologías como WPF, Silverlight, EF3 y 4... En ese año fue el pico de tecnología, sorprendentemente tecnologías como silverlight directamente se tiraron a la basura y se las deja de dar soporte. En el caso del EF5 la excusa ha sido la apertura de código. Microsoft a cogido las librerías que había para MySQL y las ha copiado en su formato para que funcionen con SQL Server. Ahora por ejemplo, necesitamos instalar numerosos paquetes en nuestro desarrollo para poder usar el EF cuando antaño no hacia falta mas que una librería. En cuanto al código, antaño con dos clases se manejaba todo, actualmente el código que genera EF5 multiplica por diez la generación de código para hacer la misma tarea que antes y ya sabemos que las lineas de código y la velocidad llevan un relación inversamente proporcional.
Semana 23 al 28 de Febrero
Comentarios
Publicar un comentario