No, no es seguro, de fundición no es seguro y que puede estallar en cualquier momento mientras se ejecuta la aplicación. Mientras que SqlConnection
deriva efectivamente de DbConnection
, no se garantiza que database.CreateConnection()
devolverá un SqlConnection
ya que esto podría parametrizarse en el archivo de configuración. Además, ¿por qué necesitas lanzar al SqlConnection
? Siempre es mejor trabajar con clases que son superiores en la jerarquía para evitar el acoplamiento de su código con una implementación específica que hará que su código sea imposible de probar de forma aislada.
Si bien EnterpriseLibrary hace un trabajo decente para mantener las cosas abstractas, lo estás matando todo con este elenco. También debe asegurarse de que los recursos desechables siempre se eliminen correctamente. ¿Qué tal esto en su lugar:
Database database = DatabaseFactory.CreateDatabase("connection string");
using (var conn = database.CreateConnection())
using (var cmd = conn.CreateCommand())
{
conn.Open();
cmd.CommandText = "SELECT id FROM foo";
using (var reader = cmd.ExecuteReader())
{
while (reader.Read())
{
// TODO: work with the results here
}
}
}
De esta manera su código es menos frágil a los cambios de la base de datos en el archivo de configuración. Bueno, por supuesto, todavía tiene este SQL codificado y hay ORM que se encargarán de esta situación. También le permitirán enfocarse en el dominio real de su aplicación en lugar de perder tiempo escribiendo consultas SQL y lanzando de un proveedor de base de datos a otro. Pero para una aplicación simple, esto está bien.
Hay un método utilizado en este código que necesita SqlConnection como un parámetro – Darqer