MCTS 70-561: Conexión a una fuente de datos

Revisando este tema recién me entero de la existencia de ConnectionStringBuilder, pues recontra útil, te evitas de problemas de que pusiste mal el nombre de “DataSource”, en lugar de “Data Source”, ya no tienes que buscar en google que opciones tiene la cadena de conexión todas están como propiedades de la clase, y algo más importante evita el injection dentro del connectionString, definitivamente una buena manera de crear un ConnectionString.

ConfigurationManager, recuerden que con esta clase podemos recuperar Settings de un archivo *.config, connectionStrings, y además una sección en particular, que es útil para editar alguna feature del archivo *.config en tiempo de ejecución. Recuerden que para aplicaciones web se recomienda el uso de WebConfigurationManager, al crear un instalador verán como es útil poder modificar dinámicamente el archivo web.config. ConfigurationManager vs WebConfigurationManager?.

No se olviden de encriptar su cadena de conexión, al hacer deployment de su aplicación Web. Usando la herramienta aspnet_regiis.exe -pe, para encriptar, y el comando aspnet_regiis.exe -pd, para desencriptar. Rápido y útil, hasta podemos tener nuestro script con este comando, cada vez que hagamos deployment. Por cierto también se puede hacer programáticamente, pero habría que darle permisos la usuario para modificar el archivo web.config. Un detalle interesante es al abrir el Snap-in de ASP.NET IIS 6.0, podemos ver y editar claramente la cadena aunque este  encriptada, en IIS 7, no soporta la visualización de la cadena de conexión encriptada, no se si quitaron este soporte, o hay que hacer algo más para ver la cadena de conexión encriptada en IIS 7.

Revisar MARS, sobre todo cuando queremos usar dos SqlDataReader bajo una misma conexión, antes no se podía usar la misma conexión para dos SqlDataReader, pero con MARS si. Por ejemplo queremos usar un SqlDataReader para recorrer un conjunto de resultados, y dentro del bucle, hacer un update, este escenario puede ser comparable con lo se hace en SQL usando cursores. Recuerden que nunca hay que explotar un feature, y hay que buscarle el escenario, revisar el excelente análisis que hace Dino Esposito, en este artículo vemos MARS en el SQL Profiler, también revisar: Introducing MARS (2), y MARS – Transactions and Debugging. Recuerden hacer el uso de Using, para un mejor manejo del pool de conexiones.

Recuerden que además de los provider soportados por ADO.NET 2.0 por defecto, OleDb, Obdc, SqlClient, y OracleClient, muchos de los providers han desarrollado su propio driver: MySql Connector/Net 5.2 (integración con VS2008), .Net data provider for Postgresql, Oracle Data Provider for .NET, DB2 for .NET, entre otros. Recuerden siempre visitar la web de los providers, para revisar si hubo alguna actualización. Tip: Algunos de los providers MySql y Oracle (hasta donde se), soportan el modelo de providers de ASP.NET 2.0, como membership y roles.

Revisar el Namespace System.Data.Common, con este podemos crear conexiones independientes del proveedor, es decir por ejemplo si queremos desplegar una aplicación que use Sql o Oracle, dependiendo de la elección del usuario, con estas clases podemos hacerlo, revisar este artículo: Writing Provider-Independent Data Access Code with ADO.NET 2.0. Aunque esto tiene sus desventajas, por ejemplo lo genérico es menos especializado, en cambio un SqlClient o un OracleClient, va aprovechar mejor determinas features de un proveedor en especifico. Habría que poner en balanza, si conviene desarrollar dos módulos en la capa de acceso a datos uno para Sql y otro para Oracle, o hacer uno genérico, claro esto dependiendo de tiempo/costo/rendimiento/performance/conocimiento.

Y para terminar no se olviden de manejar de forma adecuada los errores con las base de datos en nuestra aplicación, mostrando al usuario un mensaje amigable, y registrando para interno (logging) el código del error para saber que es lo realmente paso. Manejos de errores con SQL: Design Elements Part 3: Error Handling, Handling SQL Server Errors in Nested Procedures, y no se olviden que en una aplicación los controles de data nos permiten manejar los errores y mostrar mensajes amigables: FormView.ItemUpdated Event, el ForView, DetailsView, GridView, y ahora imagino que también el ListView, en los eventos de actualización, inserción y borrado, permiten manejar y tratar las excepciones, ah los controles XDataSource también permiten el manejo de excepciones, en todos los querys que estos hacen. Ah y por cierto cuando manejan errores en SQL, se han podido dar cuenta que pueden personalizar los mensajes de error conociendo los códigos, pues aquí les dejo una lista:

Trujillo @ Nos vemos y es todo por hoy

Saludos,

Deja un comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *