practices microsoft library example enterpriselibrary data common c# .net enterprise-library

c# - microsoft - enterprise library sql server



Ventajas y desventajas de usar Enterprise Library (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 aplicaciones de datos también proporciona una manera 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.

Estoy comenzando un proyecto y dado que este proyecto es personal, me preguntaba ¿cuáles son las ventajas de utilizar 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


Mi equipo realizó una evaluación de la biblioteca empresarial Microsoft Patterns and Practices 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 como 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.


Para el bloque de aplicación de base de datos, la principal ventaja es que facilita la producción de código independiente de la base de datos. 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 en otro cartel, el bloque de aplicaciones de datos es un poco más alto que las clases directas de ADO.NET, por lo que suele 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 desventaja de EntLib es que algunos bloques de aplicaciones colocan 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.