SQL inline è ancora classificato come una cattiva pratica ora che abbiamo Micro ORM?

Quello che stai descrivendo come "Inline SQL" dovrebbe essere chiamato "concatenazione di stringhe senza parametrizzazione", e non devi farlo per usare un Micro ORM in sicurezza.

Considera questo esempio di Dapper:

string sql = "SELECT * from user_profile WHERE FirstName LIKE @name;";
var result = connection.Query<Profile>(sql, new {name = "%"+name+"%"});

È completamente parametrizzato, anche se la concatenazione di stringhe è in corso. Vedi il segno @?

O questo esempio:

var dog = connection.Query<Dog>("select Age = @Age, Id = @Id", 
          new { Age = (int?)null, Id = guid });

che è approssimativamente equivalente al seguente codice ADO.NET:

List<Dog> dog = new List<Dog>();
using(var cmd = connection.CreateCommand()) {
    cmd.CommandText = "select Age = @Age, Id = @Id";
    cmd.Parameters.AddWithValue("Age", DBNull.Value);
    cmd.Parameters.AddWithValue("Id", guid);
    using(var reader = cmd.ExecuteReader()) {
        while(reader.Read()) {
            int age = reader.ReadInt32("Age");
            int id = reader.ReadInt32("Id");
            dog.Add(new Dog { Age = age, Id = id });
        }
    }
}

Se hai bisogno di più flessibilità di questo, Dapper fornisce modelli SQL e una funzione AddDynamicParms() . Tutto sicuro per SQL Injection.

Allora perché usare le stringhe SQL in primo luogo?

Bene, per gli stessi motivi si usa SQL personalizzato in qualsiasi altro ORM. Forse l'ORM è un codice SQL non ottimale per la generazione del codice e devi ottimizzarlo. Forse vuoi fare qualcosa che è difficile da fare in ORM in modo nativo, come UNION. O forse vuoi semplicemente evitare la complessità di generare tutte quelle classi proxy.

Se davvero non vuoi scrivere una stringa SQL per ogni metodo CRUD in Dapper ( chi lo fa?), puoi usare questa libreria:

link

Questo ti renderà estremamente semplice e intuitivo CRUD, pur continuando a darti la flessibilità delle istruzioni SQL scritte a mano. Ricorda, l'esempio di ADO.NET sopra era il modo in cui tutti lo facevano prima che arrivasse ORM; Dapper è solo un rivestimento sottile su quello.

Le query parametrizzate e il modello di progettazione del repository offrono il pieno controllo su ciò che entra nella query per prevenire attacchi di tipo injection. Inline SQL in questo caso non è un problema diverso dalla leggibilità per query complesse e complesse, che dovrebbero comunque essere in stored procedure.

Mi piace sql e non potevo sopportare di vederlo ritagliato in stringhe letterali, quindi ho scritto una piccola estensione VS per permetterti di lavorare con file sql reali in progetti c #. La modifica di sql nel proprio file ti dà intellisense per colonne e tabelle, convalida della sintassi, esecuzione del test, piani di esecuzione e il resto. Quando si salva il file, la mia estensione genera classi wrapper c #, quindi non si scrive mai una riga di codice di connessione, o codice comando, o parametro o codice lettore. Le tue query sono tutte parametrizzate perché non c'è altro modo, e hai generato repository e POCO per il test delle unità, con intellisense per i tuoi parametri di input e i tuoi risultati.

E ho lanciato coltelli da bistecca gratuiti ... Quando un esperto ha bisogno di venire a rielaborare la sql dello sviluppatore, sta guardando un vero file sql e non ha bisogno di toccare alcun C #. Quando torna indietro e riordina il DB, eliminando alcune colonne, i riferimenti alle colonne mancanti vengono visualizzati direttamente come errori di compilazione nel c #. Il database diventa proprio come un altro progetto nella tua soluzione che puoi hackerare, la sua interfaccia è individuabile nel codice. Se la soluzione viene compilata, sai che tutte le tue query funzionano. Non ci sono errori di runtime dovuti a cast non validi o nomi di colonne non validi o query non valide.

Guardando al dapper, che stiamo ancora utilizzando al lavoro, non posso credere che nel 2016 questa sia la cosa più bella nell'accesso ai dati. La generazione del ms di runtime è intelligente, ma tutti gli errori sono errori di runtime e la manipolazione delle stringhe, come la manipolazione delle stringhe per qualsiasi altro scopo, richiede tempo, è fragile e soggetta a errori. E come può essere Dry dover ripetere i nomi delle colonne nel tuo POCO, che devi scrivere e mantenere a mano.

Quindi eccoti. Se vuoi vedere una tecnologia di accesso ai dati sconosciuta da uno sviluppatore inaudito che lavora nel suo tempo libero (con un bambino piccolo e molti altri hobby), è qui .