Che tipo di progetti di sviluppo Web traggono vantaggio dall'utilizzo di ORM?

Inizierò dicendo che ho fatto il 95% del mio lavoro di database usando SQL. Di recente, ho svolto alcune indagini su vari ORM, come NHibernate e Doctrine.

Vedo i vantaggi di non aver bisogno di conoscere molto SQL e la portabilità del database fornita da un ORM. Ma posso anche vedere che conoscere SQL renderà più efficace la collaborazione con un ORM e posso solo pensare a una volta nella mia carriera che il più grande cambiamento di un'applicazione sarebbe il fornitore del database.

Poiché mi sento molto a mio agio nel scrivere SQL e apparentemente non sto realizzando i vantaggi spesso insegnati dell'utilizzo di un ORM, la mia domanda agli utenti di ORM pesanti è questa:

Che tipo di progetti di sviluppo Web traggono maggiori benefici dall'uso di ORM?

(Quasi) tutte le applicazioni beneficiano di ORM.

Innanzitutto, non sono d'accordo con i vantaggi che elenchi per ORM .

• L'uso di ORM non significa necessariamente che non è necessario conoscere SQL. Una conoscenza di SQL aiuterà a capire cosa sta effettivamente facendo lo strumento ORM, che è particolarmente utile durante il debug. Inoltre, SQL potrebbe effettivamente essere richiesto per sviluppare query complesse che vanno oltre le capacità dell'ORM scelto.
• E come dici tu, la portabilità raramente è una preoccupazione nella vita reale.

Invece, i vantaggi reali di ORM sono:

• ORM consente di risparmiare tempo al programmatore perché consente di risparmiare tonnellate di logica CRUD in SQL
• molti ORM includono una complessa logica di memorizzazione nella cache ecc. che è difficile da scrivere ed eseguire il debug. Oltre a risparmiare tempo, questo può migliorare l'affidabilità e la manutenibilità della tua applicazione (o almeno farti risparmiare il tempo necessario per ottenere gli stessi risultati)
• i migliori ORM hanno una comunità di utenti che sviluppano, gestiscono e supportano attivamente il prodotto. La comunità attorno all'SQL personalizzato è, nella migliore delle ipotesi, un po 'meno focalizzata sui problemi che dobbiamo risolvere.

Come commentate, un lato negativo di ORM è una perdita di prestazioni. Tuttavia, questo può essere generalmente compensato spendendo più hardware.

In genere, il tempo del programmatore è più costoso dell'hardware, quindi ORM è generalmente una buona opzione invece di codificare manualmente SQL.

ORM è la soluzione migliore per le applicazioni con una logica del database CRUD abbastanza semplice. ORM è meno efficace per :

• Applicazioni che richiedono poco / nessun accesso al database.
• Applicazioni che dipendono in gran parte da query complesse e da una logica CRUD molto semplice
• Situazioni in cui le prestazioni sono critiche, ma in cui non è possibile distribuire hardware più veloce

Nella mia esperienza, queste situazioni sono rare. Da qui la mia risposta.

Mi sento a mio agio anche a scrivere SQL. Sono anche molto più a mio agio nel non dover scrivere alcun SQL, così come non preoccuparmi di collegarmi, disconnettermi, raggruppare, ecc. In un database.

Quindi .. risponderò al negativo della tua domanda. Gli unici progetti di sviluppo Web che NON beneficiano di un ORM sono quelli che non parlano affatto con un database. Che credo siano la minoranza (se presente).

In base alla mia esperienza con ASP.NET WebForms, proporrei che i progetti Web che utilizzano framework Web con stato traggano il massimo beneficio dall'utilizzo di un ORM.

Con un framework stateful il markup viene generato automaticamente dietro le quinte, in base alla gerarchia dei controlli server attivi. Si è tentati di caricare e mantenere tali controlli automaticamente nel database. Questo è dove ORM aiuta.

In un certo senso si estrae la fine della pipeline (output HTML) ed è naturalmente invitante trattare l'inizio (origine dati) allo stesso modo in modo da rimanere all'interno della propria logica aziendale nel codice dell'applicazione.

Non che non sto dicendo che questo è un buon modo di fare le cose. È proprio dove ORM si adatta naturalmente.

Nelle applicazioni in cui si dispone di un modello di oggetti di grandi dimensioni e molto connesso, un ORM consente di evitare di scrivere più volte gli stessi join.

Un altro vantaggio è il caricamento lento, in cui si desidera che un'API restituisca un grafico a oggetti in cui il client dell'API utilizzerà solo un sottoinsieme di tale grafico.

Credo che tu stia confondendo un ORM con un DBAL .

Il concetto a cui ti riferisci è un Database Abstraction Layer (DBAL) che ti consente di scrivere "sql" portatile che non dipende dal sistema di database sottostante.

D'altra parte un ORM (che è (quasi?) Sempre costruito sopra un DBAL):

Object-relational mapping (ORM, O/RM, and O/R mapping) in computer software is a programming technique for converting data between incompatible type systems in object-oriented programming languages. This creates, in effect, a "virtual object database" that can be used from within the programming language. (Wikipedia)

In poche parole, un ORM consente di convertire i dati da un database piatto in una rappresentazione di oggetti gonfiati.

I progetti che non trarrebbero beneficio da ORM sarebbero:

• quelli che non sono orientati agli oggetti;
• quelli che non necessitano di conservare i dati;
• quelli che usano DB orientati agli oggetti, quindi non necessitano di layer di mappatura aggiuntivi;
• quelli che usano una soluzione NoSQL non relazionale;