Perché dovresti usare un ORM? [chiuso]

Se dovessi motivare i "pro" del motivo per cui useresti un ORM per il management / cliente, quali sarebbero le ragioni?

Cerca di conservare un motivo per risposta in modo che possiamo vedere quali sono i motivi migliori per i voti

Rendere l'accesso ai dati più astratto e portabile. Le classi di implementazione ORM sanno come scrivere SQL specifico del fornitore, quindi non è necessario.

Il motivo più importante per utilizzare un ORM è poter disporre di un modello di business ricco e orientato agli oggetti ed essere comunque in grado di archiviarlo e scrivere query efficaci rapidamente su un database relazionale. Dal mio punto di vista, non vedo alcun reale vantaggio che un buon ORM ti offre rispetto ad altri DAL generati diversi dai tipi avanzati di query che puoi scrivere.

Un tipo di query a cui sto pensando è una query polimorfica. Una semplice query ORM potrebbe selezionare tutte le forme nel database. Ottieni indietro una raccolta di forme. Ma ogni istanza è un quadrato, un cerchio o un rettangolo secondo il suo discriminatore.

Un altro tipo di query potrebbe essere quella che recupera con impazienza un oggetto e uno o più oggetti o raccolte correlati in una singola chiamata al database. Ad esempio, ogni oggetto forma viene restituito con i suoi vertici e le raccolte laterali popolate.

Mi dispiace non essere d'accordo con così tanti altri qui, ma non penso che la generazione del codice sia una ragione sufficiente di per sé per andare con un ORM. Puoi scrivere o trovare molti buoni modelli DAL per generatori di codice che non hanno l'overhead concettuale o di prestazioni che fanno gli ORM.

Oppure, se pensi di non aver bisogno di sapere come scrivere un buon SQL per usare un ORM, ancora una volta, non sono d'accordo. Potrebbe essere vero che dal punto di vista della scrittura di singole query, affidarsi a un ORM è più semplice. Ma con gli ORM è fin troppo facile creare routine con prestazioni scadenti quando gli sviluppatori non capiscono come funzionano le loro query con l'ORM e l'SQL in cui si traducono.

Avere un livello dati che funzioni su più database può essere un vantaggio. Non è uno su cui ho dovuto fare affidamento spesso però.

Alla fine, devo ribadire che nella mia esperienza, se non stai utilizzando le funzionalità di query più avanzate del tuo ORM, ci sono altre opzioni che risolvono i problemi rimanenti con meno apprendimento e meno cicli di CPU.

Oh sì, alcuni sviluppatori trovano che lavorare con gli ORM sia divertente, quindi gli ORM sono buoni anche dal punto di vista del mantenimento della felicità degli sviluppatori. =)

Accelerare lo sviluppo. Ad esempio, eliminando il codice ripetitivo come la mappatura dei campi dei risultati delle query sui membri degli oggetti e viceversa.

Supporto dell'incapsulamento OO delle regole aziendali nel livello di accesso ai dati. È possibile scrivere (ed eseguire il debug) delle regole di business nella lingua di preferenza dell'applicazione, anziché nei linguaggi goffi di trigger e procedure memorizzate.

Generazione di codice boilerplate per operazioni CRUD di base. Alcuni framework ORM possono esaminare direttamente i metadati del database, leggere i file di mapping dei metadati o utilizzare proprietà di classe dichiarative.

È possibile passare facilmente a un software di database diverso perché si sta sviluppando un'astrazione.

In modo che il modello a oggetti e il modello di persistenza corrispondano.

Felicità dello sviluppo, IMO. ORM astrae molte delle cose bare metal che devi fare in SQL. Mantiene la base del codice semplice: meno file sorgente da gestire e le modifiche allo schema non richiedono ore di manutenzione.

Attualmente sto utilizzando un ORM e ha accelerato il mio sviluppo.

Per ridurre al minimo la duplicazione di semplici query SQL.

Il motivo per cui lo sto esaminando è evitare il codice generato dagli strumenti DAL di VS2005 (mappatura dello schema, TableAdapter).

Il DAL / BLL che ho creato più di un anno fa funzionava bene (per quello per cui l'avevo costruito) fino a quando qualcun altro non ha iniziato a usarlo per sfruttare alcune delle funzioni generate (che non avevo idea ci fossero)

Sembra che fornirà una soluzione molto più intuitiva e pulita rispetto alla soluzione DAL / BLL da http://wwww.asp.net

Stavo pensando di creare il mio generatore di codice SQL Command C # DAL, ma ORM sembra una soluzione più elegante

Compilazione e verifica delle query.

Man mano che gli strumenti per gli ORM migliorano, è più facile determinare la correttezza delle query più rapidamente attraverso errori e test in fase di compilazione.

La compilazione delle query aiuta gli sviluppatori a trovare gli errori più velocemente. Destra? Destra. Questa compilazione è resa possibile perché gli sviluppatori ora scrivono query nel codice utilizzando i propri oggetti o modelli di business anziché solo stringhe di istruzioni SQL o SQL.

Se si utilizzano i modelli di accesso ai dati corretti in .NET, è facile eseguire un test unitario della logica di query rispetto alle raccolte di memoria. Ciò accelera l'esecuzione dei test perché non è necessario accedere al database, impostare i dati nel database o persino avviare un contesto dati completo. [EDIT] Questo non è vero come pensavo fosse come unità i test in memoria possono presentare sfide difficili da superare. Ma trovo ancora questi test di integrazione più facili da scrivere rispetto agli anni precedenti. [/ EDIT]

Questo è decisamente più rilevante oggi rispetto a pochi anni fa, quando è stata posta la domanda, ma potrebbe essere il caso solo per Visual Studio ed Entity Framework dove risiede la mia esperienza. Plugin il tuo ambiente, se possibile.

Astrarre lo sql via il 95% delle volte, quindi non tutti i membri del team devono sapere come scrivere query specifiche per database super efficienti.

Penso che ci siano molti punti positivi qui (portabilità, facilità di sviluppo / manutenzione, focus sulla modellazione aziendale OO ecc.), Ma quando si cerca di convincere il proprio cliente o la direzione, tutto si riduce a quanto denaro si risparmia utilizzando un ORM .

Esegui alcune stime per attività tipiche (o anche progetti più grandi che potrebbero essere in arrivo) e otterrai (si spera!) Alcuni argomenti per il passaggio che sono difficili da ignorare.

Livelli .net che utilizzano modelli di code smith

http://nettiers.com/default.aspx?AspxAutoDetectCookieSupport=1

Perché codificare qualcosa che può essere generato altrettanto bene.

convincili quanto tempo / denaro risparmierai quando verranno apportate modifiche e non dovrai riscrivere il tuo SQL poiché lo strumento ORM lo farà per te

Penso che uno svantaggio sia che ORM avrà bisogno di un aggiornamento nel tuo POJO. principalmente relativi a schema, relazione e query. quindi lo scenario in cui non si suppone di apportare modifiche agli oggetti del modello, potrebbe essere perché è condiviso tra più che sul progetto o client e server in b / n. quindi in questi casi sarà necessario dividerlo in due livelli, il che richiederà ulteriori sforzi.

Sono uno sviluppatore Android e, come sapete, le app mobili di solito non hanno dimensioni enormi, quindi questo sforzo aggiuntivo per separare il modello puro e il modello interessato dall'orm non sembra valere la pena.

capisco che la domanda è generica. ma anche le app mobili sono contenute all'interno di un ombrello generico.