8/11/2010 13:19
El Bruno
[ENTLIB] ¿Porqué a la gente no le gusta Enterprise Library?
Buenas,
hace un par de días escribí un post donde comentaba el roadmap de Enterprise Library para el año 2011 y como el mismo apuntaba a dar soporte a ASP.Net MVC y a Silverlight. Al margen de lo bueno o malo de esto, una vez más me encontré con amiguetes y compañeros que le pegan a EntLib por donde menos le duele, en este caso por Twitter Rodrigo (@r_corral) y Javi (@jcalvarro); y en vivo un par más. Así que, intentando ser neutral (como un suizo como me diría Hadi @hhariri), comentaré lo que usualmente escucho sobre EntLib y mi opinión al respecto.
1. Algunos bloques están desfasados
Pues sí y es una pena que no los saquen de la lista de bloques, porque seguir teniendo un bloque para la gestión de la seguridad no tiene sentido. Por ejemplo, desde Visual Studio 2005 los Membership Providers dan una excelente solución para escenarios de autenticación y autorización, no veo necesario seguir manteniendo el Application Block de Seguridad (ni hablar de WIF, etc). Otro ejemplo es el Caching Aplicacion Block. El mismo tenía su razón de ser cuando queríamos tener capacidades de Caching en entornos no Web por favor, no agregues como referencia System.Web en una aplicacion Windows; pero ahora que .Net Framework 4.0 tambíen nos dá esta capacidad, pues bueno, será momento de ir reciclando.
Un dato en este punto, varias de las funcionalidades que posee EntLib, han llegado luego al Framework y se han eliminado de EntLib. El mejor ejemplo, es tal vez la gestión de la configuración que antes de .Net Fwk 2.0 era un poco infierno y el Application Block de Configuración era una ayuda que se agradecía; ahora con System.Configuration pues ya tenemos el problema resuelto.
2. La ejecución de los bloques es muy lenta
Este es otro de los argumentos que dan para debatir un rato largo. Por lo general aplica al Logging Application Block, pero yo aqui siempre intento hacer un ejercicio para ver la mejor solución posible porque no todas las aplicaciones tienen requerimientos funcionales que necesiten grabar millones de logs por milisegundo y si lo tienen, seguramente tampoco .Net pelado es una opción. Comento un ejemplo reciente.
En un cliente utilizamos LAB (Logging Application Block) para dar soporte a un sistema de mensajería interna y trazas entre aplicaciones. Como la app funciona correctamente, un directivo, en un acto que demuestra su inteligencia y su gran capacidad de razonamiento propone mover el esquema físico de la aplicación a todas las dependencias de la empresa en España, Portugal, Francia, etc. Vamos que sin preguntar, cae un marrón de esos que asustan. A mi personalmente, estas decisiones poco me importan, ya que si se puede –> BIEN, y sino se puede o es una venta de humo; pues se hace BIEN O NOS VAMOS. Pero le dimos una pensada y una pensada de las buenas, y llegamos a la conclusión de que aprochando las capacidades de trabajo asíncronas con colas MSMQ de LAB podiamos desplegar la aplicación, centralizar la grabación de logs y cambiar de repositorio desde el visor de eventos a una base de datos SQL, sin tocar una línea de código, simplemente modificando la configuración. Comento este caso, porque un compañero estaba dispuesto a escribir un artefacto de la muerte encargado de hacer todo este trabajo, y yo intenté hacer de “suizo” para obtener la mejor solución posible. En el ejemplo anterior, después de analizarlo lo importante no era “la velocidad” de ejecución de los bloques, sino la capacidad de los mismos; para velocidad algún día comentaré las trazas de una aplicación de banca que realmente asustaba 
.
Un dato final, es cierto que en las versiones iniciales de EntLib la carga de ensamblados era muy lenta, ya que la creación de objetos se realizaba con una factoria llamada ObjectBuilder, que creaba tipos por reflection a partir de una configuración, etc. Ahora con Unity, este modelo ha cambiado completamente y la “sobrecarga” de trabajo es la que posee Unity; además se ha deshabilitado por defecto la notificación de eventos, se han eliminado los eventos WMIs, etc.
3. Prefiero escribir el código sensible de una aplicación yo mismo
Aquí hay discusión para rato, y no las clásicas “yo soy más inteligente que los de Patterns and Practices”, o que “los de P&P son muy feos”; sino más bien relacionada con el contexto de negocio de una aplicación. Me explico; los bloques de trabajo de Enterprise Library son muy generalistas, son soluciones generales a problemas usuales. Si bien, creo que cubren la casuística de muchos escenarios, en algunos casos es necesario optar por una solución propia o modificar alguna parte de EntLib para dar por cerrado estos problemas.
Por otra parte, EntLib es código abierto, asi que puedes leerlo y criticarlo todo lo que quieras. De buena fuente, sé que el equipo de P&P están abiertos a recomendaciones y cambios. Un ejemplo de ello, es que en EntLib4, se entregaban todos los bloques y Unity como componentes separados; pero era un poco “cantoso” que la propia EntLib no se desacoplara utilizando Unity, asi que en EntLib5 ya está todo desacoplado.
Volviendo a los términos “codigo sensible” y “yo mismo”; pues aquí mi recomendación es: cuidado. Muchas veces queremos ser mejores que el mejor y a la larga los que sufren las consecuencias son nuestros clientes eso en mi caso que a mi nómina me la pagan mis clientes y ellos tienen que estar contentos y satisfechos , si a tus clientes no les importa que las aplicaciones no funciones o que los proyectos se atrasen pues te envidio Aunque si lo que escribes es mejor o más útil, pues compártelo que para eso estamos.
Podría seguir escribiendo un buen rato, ya que he escuchado otros puntos como:
Finalmente, si tienes algo que comentar del porqué no te gusta Enterprise Library, Codeplex es un excelente lugar o este post para ver una versión en español.
Saludos @ Here
El Bruno
Archivado en: Enterprise Library,Opinion
Comparte este post: