Sto usando il micro-ORM PetaPoco. È davvero molto facile e sicuro lavorare con i database usando gli strumenti ORM, ma l'unica cosa che odio è il codice extra. Ero solito inserire la maggior parte del codice nel database stesso e utilizzare tutte le funzionalità RDBMS come Stored Procedure, Trigger ecc., Che è stato progettato per gestire meglio.
Voglio sapere quando non usare ORM su stored procedure / trigger e viceversa.
Gli ORM non si escludono a vicenda con Stored Procedures. La maggior parte degli ORM può utilizzare stored procedure. La maggior parte degli ORM genera stored procedure se lo si desidera. Quindi il problema non è né o.
Gli ORM possono generare SQL non accettabile (in termini di prestazioni) e talvolta si può voler sovrascrivere quello SQL con SQL artigianale. Uno dei modi per farlo è usando SP.
In DotNet, non utilizzare stored procedure se:
Se non hai familiarità con le stored procedure (non il tuo caso, ma incluso per completezza).
Se non vuoi introdurre uno strato di complessità e versatilità nel tuo progetto.
Stai creando un'applicazione che dovrebbe funzionare con diversi database o che dovrebbe essere replicata su diversi server di database (quest'ultima restrizione potrebbe applicarsi solo per alcuni database).
Nota che i trigger non devono essere confrontati con gli ORM. I trigger eseguono funzioni che non sono migliori nel codice dell'applicazione (come la registrazione o la sincronizzazione dei dati tra database).
Alcune persone preferiscono l'uso di stored procedure su SQL nel codice per diversi motivi come la sicurezza (ad esempio per prevenire l'iniezione SQL) e per la loro velocità dichiarata. Tuttavia, questo è un po 'discutibile e richiede una discussione dettagliata.
Se il tuo ORM non è in grado di generare stored procedure e devi scrivere un sistema di grandi dimensioni, devi pesare la codifica manuale aggiuntiva basata sul tuo caso.
Gli ORM spesso presumono che il database esista per servire l'ORM. Ma di solito il database esiste per servire l'azienda, che potrebbe avere centinaia e centinaia di app scritte in più lingue che lo colpiscono.
Ma è solo un caso di "ORM rispetto alle stored procedure" se stai usando un ORM che non può chiamare una stored procedure. Altrimenti, è un caso di decidere dove codificare la logica aziendale.
Ovunque si codifichi la logica aziendale, il suo compito è quello di assicurarsi che il database cambi da uno stato coerente a un altro stato coerente indipendentemente da quale applicazione apporti la modifica . Quindi in realtà hai solo due scelte pratiche: codificale una volta nel database o codificale una volta in un livello di accesso ai dati "impenetrabile".
Fai attenzione all'interfaccia della riga di comando di dbms se usi un DAL "impenetrabile".
Query semplice - > ORM
Query complessa - > Procedura memorizzata
Il trigger dovrebbe essere usato come invariante di record o consistere in regole aziendali vitali, IMHO.
I problemi di orms:
Non sono d'accordo. La query ORM è più semplice se conosci ORM meglio di quanto sai SQL. ORM risulta in molto più codice, molto più difficile da mantenere IMO. Le uniche persone che beneficiano di ORM sono gli azionisti della società che vende l'ORM (ad esempio Microsoft).
Leggi altre domande sui tag rdbms orm stored-procedures