Quali sono alcuni dei vantaggi di un "Micro-ORM"?

Ho esaminato i cosiddetti "Micro ORM" come Dapper e (in misura minore in quanto si basa su .NET 4.0) Enormi in quanto potrebbero essere più facili da implementare sul lavoro rispetto a un ORM completo dal nostro sistema attuale dipende fortemente dalle procedure memorizzate e richiederebbe un significativo refactoring per funzionare con un ORM come NHibernate o EF. Qual è il vantaggio di utilizzare uno di questi su un ORM completo? Sembra solo uno strato sottile intorno una connessione al database che le forze ancora di scrivere SQL prime - forse mi sbaglio, ma mi ha sempre detto che la ragione per ORM in primo luogo, è così non è stato necessario scrivere SQL, potrebbe essere generato automaticamente; specialmente per i join multi-tabella e le relazioni di mappatura tra tabelle che sono una seccatura da fare in SQL puro ma banali con un ORM.

Ad esempio, guardando un esempio di Dapper:

var connection = new SqlConnection(); // setup here...
var person = connection.Query<Person>("select * from people where PersonId = @personId", new { PersonId = 42 });

In che modo è diverso dall'uso di un livello dati ADO.NET gestito a mano, tranne per il fatto che non è necessario scrivere il comando, impostare i parametri e suppongo di mappare nuovamente l'entità usando un Builder. Sembra che potresti persino usare una chiamata di procedura memorizzata come stringa SQL.

Ci sono altri vantaggi tangibili che mi mancano qui in cui un ORM Micro ha senso usare? Non vedo davvero come stia risparmiando qualcosa sul "vecchio" modo di usare ADO.NET tranne forse alcune righe di codice - devi ancora scrivere per capire quale SQL devi eseguire (che può diventare peloso) e devi ancora mappare le relazioni tra le tabelle (la parte con cui gli ORM IMHO aiutano di più).

Benefici:

• Prestazioni simili a un SqlCommand non elaborato con DataReader e analisi.
• Non è necessario creare il proprio livello di conversione per DataReader.

È praticamente tutto, a dire il vero. Hai un wrapper molto leggero per le tue connessioni sql che farà la conversione degli oggetti per te. Ovviamente, è possibile ottimizzare le query senza dover gestire alcun SQL generato automaticamente.

Contro:

• Neanche un po 'dilemma. Se esegui un refuso nell'SQL il tuo server CI non lo catturerà, dovrai sperare che venga rilevato durante l'interfaccia utente automatizzata o il test funzionale.
• Un dolore da mantenere. Hai un sacco di istruzioni SQL in linea che eseguono varie query che non hanno legami forti con l'architettura DB. Questo può facilmente portare a query che vengono "lasciate indietro" quando cambia la struttura del database sottostante, che, di nuovo, non vedrai al momento della compilazione.

Hanno il loro posto e sono uno strumento molto efficace che può togliere parte del "lavoro dell'asino" dagli sviluppatori quando interagiscono con il DB, ma in realtà semplicemente non possono prendere il posto di un ORM completo in nessuna grande scala sistema per query non critiche per le prestazioni, semplicemente a causa dell'aumento dei costi di manutenzione.

Se hai difficoltà con le prestazioni sulle query DB, suggerirei che sarebbe meglio usare questi framework di mappatura solo con Stored Procedures, al fine di ottenere un'indicazione in fase di compilazione se il tuo SQL è valido (oltre ai vantaggi aggiuntivi sulle prestazioni) .

Nel sito web del micro ORM PetaPoco spiega alcuni vantaggi con altri ORM. per spiegare di più

PetaPoco è un micro-ORM minuscolo, veloce, a file singolo per .NET e Mono.

• Come Massive è un singolo file che puoi facilmente aggiungere a qualsiasi progetto
• A differenza di Massive, funziona con POCO fortemente tipizzati
• Come Massive, ora supporta anche le espansioni dinamiche - leggi di più
• Come ActiveRecord, supporta una stretta relazione tra oggetto e tabella del database
• Come SubSonic, supporta la generazione di classi poco con modelli T4
• Come Dapper, è veloce perché utilizza la generazione di metodo dinamico (MSIL) per assegnare valori di colonna alle proprietà

In che modo è diverso dall'uso di un livello dati ADO.NET gestito a mano, tranne per il fatto che non è necessario scrivere il comando, impostare i parametri e suppongo di mappare nuovamente l'entità usando un Builder. Sembra che potresti persino usare una chiamata di procedura memorizzata come stringa SQL.

Credo che sia il principale vantaggio di un Micro-ORM, per ottenere gli altri benefici di un ORM è necessario utilizzarne uno completo. Quello e il codice sono relativamente più piccoli, quindi se è necessario personalizzarlo, sarebbe più facile.