Ventajas y desventajas de usar Enterprise Library

Question

Estoy comenzando un proyecto y dado que este proyecto es personal, me preguntaba ¿cuáles son las ventajas de usar Enterprise Library? Usamos la versión 2 para varios proyectos en la oficina, pero no estoy seguro (aparte de las buenas prácticas) de sus ventajas, especialmente en el componente de la base de datos. ¿Algún consejo? Gracias

Answer 1

Para el bloque de aplicación de base de datos, la principal ventaja es que facilita la producción de código de base de datos independiente. El desarrollador interactúa principalmente con objetos genéricos de base de datos y de DbCommand, en lugar de, por ejemplo, SqlConnection, SqlCommand, etc. Por lo tanto, el cambio a una base de datos diferente (es decir, Oracle) se vuelve más factible. Dependiendo de las necesidades de su negocio, esta podría ser una ventaja definitiva. EntLib también empuja suavemente al desarrollador en el sentido de utilizar DbParameter para los parámetros de consulta, lo que reduce el riesgo de ataques de inyección SQL.

Como se menciona otro cartel, el bloque de aplicación de datos es algo más alto que las clases ADO.NET rectas, por lo que tiende a requerir menos líneas de código para hacer lo mismo.

Desde mi punto de vista, los bloques de datos, excepción y registro son los más útiles. La excepción y el registro juntos hacen que sea muy fácil registrar excepciones (duh) en varios lugares y en varios formatos. Por ejemplo, pueden colocar toda la entrada del registro de excepción, incluido el seguimiento de la pila, en el registro de eventos de Windows, lo que hace que sea relativamente fácil diagnosticar un problema.

Una de las desventajas de EntLib es que algunos bloques de aplicaciones ponen bastante lógica en los archivos de configuración. Entonces tu lógica está más extendida; algo de eso está en código, algunos en archivos de configuración. Lo bueno es que la configuración se puede modificar después de la compilación e incluso después de la implementación.

Answer 2

Mi equipo hizo una evaluación de Microsoft Patterns and Practices Enterprise Library hace aproximadamente 2 años como parte de una reingeniería de nuestra línea de productos. La única parte que terminamos usando fue el bloque de la base de datos. Incluso incluimos eso en algunas clases que pudimos instanciar para poder simular el DAL para pruebas unitarias; el bloque de código de Microsoft usaba llamadas estáticas para el trabajo de la base de datos. No estoy seguro de si Microsoft ha integrado alguna de las cosas LINQtoSQL o Entity Framework en el bloque db. Sería reacio a usar el bloque db ahora si no aprovechase uno de esos.

En lo que respecta al registro, encontramos que Log4Net es una solución mucho más robusta y flexible que el registro de Microsoft. Fuimos con eso para nuestras necesidades de registro.

Para el manejo de excepciones, lanzamos el nuestro. El código de Microsoft no manejaba los casos remotos que queríamos manejar, y dado que estábamos usando un marco de registro de terceros, tenía más sentido escribir nuestra propia biblioteca de excepciones e integrar con eso. He descubierto que puede ser muy útil algún nivel de integración del marco de trabajo de registro en el marco de excepción. Escribimos algunas clases de envoltura ligera alrededor de Log4Net y las llamamos de nuestro registro de excepciones para no introducir dependencias en Log4Net.

Answer 3

Además de los elementos mencionados por Paul sobre el bloque de aplicación de datos, también me gustaría señalar que en mi experiencia el bloque de aplicación de datos proporciona una forma mucho más rápida de escribir el código de base de datos necesario, con los ayudantes que existen . Lo uso por su apariencia/sensación consistente y la velocidad de desarrollo.