No, non è sicuro, la fusione non è mai al sicuro e può saltare in qualsiasi momento mentre l'applicazione è in esecuzione. Mentre SqlConnection
deriva effettivamente da DbConnection
non è garantito che database.CreateConnection()
restituirà un valore SqlConnection
in quanto potrebbe essere parametrizzato nel file di configurazione. Inoltre, perché devi trasmettere a SqlConnection
? È sempre meglio lavorare con classi che sono più in alto nella gerarchia per evitare di accoppiare il codice con un'implementazione specifica che renderà il tuo codice impossibile da testare da solo.
Mentre EnterpriseLibrary fa un lavoro decentemente buono nel mantenere le cose astratte, stai uccidendo tutto con questo cast. Inoltre, è necessario assicurarsi che le risorse disponibili siano sempre smaltite correttamente. Che ne dite di questo, invece:
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
}
}
}
In questo modo il codice è meno fragile di modifiche del database nel file di configurazione. Beh, certo, hai ancora questo codice SQL hardcoded e ci sono ORM che si prenderanno cura di questa situazione. Ti consentiranno inoltre di concentrarti sul vero dominio della tua applicazione invece di perdere tempo scrivendo query SQL e trasmettendo da un provider di database a un altro. Ma per una semplice applicazione questo è OK.
fonte
2010-09-05 19:45:43
Esiste un metodo utilizzato in questo codice che richiede SqlConnection come parametro – Darqer