Quali sono i vantaggi dell'utilizzo dell'astrazione del database da parte di ORM? [chiuso]

Sto iniziando a utilizzare l'ORM raccomandato dal framework che scelgo e, sebbene mi piaccia l'idea del livello aggiuntivo di astrazione fornito dall'ORM, sto iniziando a capire cosa significhi davvero. Significa che non sto più lavorando con il mio database (mysql) e tutte le funzionalità specifiche di mysql sono sparite, fuori dalla finestra, come se non esistessero.

L'idea dell'ORM è che sta cercando di aiutarmi rendendo tutto il database agnostico. Sembra fantastico, ma spesso c'è un motivo per cui scelgo un sistema di database specifico. Ma seguendo il percorso agnostico del database, l'ORM prende il minimo comune denominatore, il che significa che finisco con il più piccolo set di funzionalità (quelle supportate da tutti i database).

Cosa succede se so che a lungo termine non cambierò il database sottostante? Perché non accedere anche alle funzionalità specifiche del database?

Lo vedo allo stesso modo. Qualsiasi astrazione che non ti permetta di passarci sotto quando è necessario è malvagia, perché porta a ogni sorta di brutte inversioni di astrazione nel tuo codice.

Al lavoro abbiamo un ORM nostrano che funziona abbastanza bene, ma per i momenti in cui abbiamo bisogno di qualcosa che le sue caratteristiche non prevedono esplicitamente, c'è un metodo che prende una stringa e la rilascia direttamente nella query che sta generando, permettendo per l'uso di SQL non elaborato quando è necessario.

IMO qualsiasi ORM che non ha questa funzione non vale i bit da cui è stata compilata.

l'ORM prende il minimo comune denominatore

Non sono d'accordo con la tua affermazione. Prenderò NHibernate come esempio. Questo framework supporta molti database, inclusi quelli più popolari, indipendentemente dalla versione (e dalle funzionalità supportate), proprio come la maggior parte degli ORM.

Nota rapida: menzioni solo l'astrazione del database. Questo è uno dei tanti vantaggi, ma penso davvero che le funzionalità orientate agli oggetti siano più potenti (ad esempio: ereditarietà). E You design your domain model first...

... Ritorno all'astrazione. Non è il minimo comune denominatore. In nHibernate , hai dialetti. Ti consente di utilizzare uno stesso codice per eseguire query su database diversi. I dialetti si occupano della gestione delle funzionalità per te. L'affermazione corretta è quella a given dialect will try to use all the power of a given database system.

Ad esempio, prendiamo il SqlServer2005dialetto che, quando introdotto, sfruttava le nuove funzionalità di paging di SQL Server 2005. Usare quel dialetto invece di SqlServer2000aumentare semplicemente le tue esibizioni.

Ovviamente ci sono delle eccezioni, ma non ne ho incontrato uno in molti anni di lavoro con nHibernate e le mie applicazioni sono molto incentrate sui dati.

L'idea è chiara, ma non sono mai stato spostato al punto di utilizzare uno strumento ORM. Semplicemente non è stato un problema per me scrivere l'SQL da solo (o gestire qualsiasi memoria venga utilizzata). Ma ho il lusso di lavorare su un numero minore di progetti con una vita dei prodotti più lunga, quindi una volta che la manipolazione di SQL e DB codificata a mano è in atto, è a posto. Inoltre, puoi ovviamente gestire qualsiasi query SQL diretta di cui hai bisogno senza dover adattare il tuo processo al modo di pensare dello strumento ORM.

Quindi, suppongo che le domande dovrebbero essere prima di saltare in uno:

Stai effettivamente ottenendo qualcosa dall'usarli? Cioè, stai risparmiando una quantità sufficiente di sforzo implementando uno strumento ORM per renderlo utile e per renderlo utile aggiungere una complicazione aggiuntiva al tuo sistema? (questo è particolarmente vero per le app commerciali, in cui quel "pezzo" in più è ora un vettore in più per potenziali problemi di supporto)

E poi, il livello di astrazione aggiuntivo avrà un impatto negativo sull'app? Sarà più lento di SQL codificato a mano, ecc.

O / RM è stato regolarmente criticato. Ted Neward lo ha definito il " Vietnam dell'informatica " alcuni anni fa. O / RM

inizia bene, diventa più complicato col passare del tempo e in breve tempo intrappola i suoi utenti in un impegno che non ha un chiaro punto di demarcazione, nessuna chiara condizione di vittoria e nessuna chiara strategia di uscita.

A meno che tu non scriva la tua mappatura ad hoc (che è una buona soluzione in molti casi, come altri hanno già detto), potresti guardare alternative come l'uso di un database non relazionale. Alcuni sostengono che un database di oggetti veramente sia migliore, altre parole d'ordine menzionate in questo contesto sono LINQ, Ruby e Tutorial D. Suppongo che, contrariamente ai database veramente relazionali, ci siano database di oggetti veramente. Ma in pratica ho scoperto che la modellazione di dati concettuali - vale a dire, su quali oggetti del mondo reale vuoi archiviare i dati e su come questi oggetti si relazionano tra loro - è più importante che armeggiare su come esprimere il tuo modello concettuale in qualsiasi linguaggio di programmazione o database.

Qual è l'alternativa?

Questa è una nozione interessante. Astrarre le funzionalità del database sottostante perdiamo sicuramente alcune delle funzionalità dell'implementazione specifica del database. (Indipendentemente dal fatto che dovremmo dipendere da specifiche funzionalità del database è un altro argomento) Immagino che questo potrebbe essere risolto da ORM specifici del database che ti consentono di accedere alle funzionalità specifiche, ma potrebbe essere solo un problema maggiore di quanto valga la pena e un passaggio nel direzione sbagliata.

Alla fine della giornata, devi chiederti: qual è l'alternativa?

Dovremmo smettere di usare gli ORM e tornare a scrivere da soli tutti gli accessi al database? Sicuramente potremmo perdere l'accesso ad alcune funzionalità del database tramite l'ORM, ma puoi sempre accedere a quelle usando le tecniche della vecchia scuola. Alla fine i guadagni ottenuti in termini di produttività superano completamente gli svantaggi.

Un ORM equivale sostanzialmente a " Procedure non memorizzate ". Lì ho coniato un termine.

Tutto ciò che fa un ORM, è possibile replicarlo con visualizzazioni, trigger e stored procedure. Aiutano a sottrarre SQL grezzo e possono mantenere coerenti i database normalizzati. Ma funziona bene solo per casi semplici. Se i dati mach sono troppo elaborati per l'elaborazione, possono diventare un consumo di prestazioni. (Gli ORM in PHP prendono spesso il lato script dei dati, perché le catene del builder SQL non possono astrarre tutto.)

Ma come al solito, tutto dipende dall'applicazione e dal compito da svolgere.

Una cosa che fa male usando gli ORM è che molti dei loro fan tendono a sostenere che non abbiamo più bisogno di conoscere la teoria di SQL e RDB. I risultati variano da divertenti a completamente catastrofici. E questo nonostante le milioni di volte in cui i produttori e gli esperti di ORM affermano che dobbiamo conoscere bene la teoria SQL e RDB per utilizzare e configurare correttamente un ORM.

Perché la gente prende uno strumento che ha i suoi usi su molti, ma non tutti i contesti, in un proiettile d'argento magico, universalmente applicabile, va oltre me.

L'anno scorso ho lavorato su un'app interna che cambiava frequentemente ed ero molto felice di aver usato un ORM. L'app era un'app di supporto per un team di gestione delle modifiche e, poiché il progetto più ampio si è evoluto, la nostra piccola app ha ottenuto nuovi requisiti per situazioni che non esistevano e non potevano essere previste pochi mesi prima.

Grazie a ORM ( Propel , in PHP), abbiamo diviso parte della logica per il codice, quindi una funzione ha aggiunto la parte "è record valido" della query, un'altra la parte di sicurezza ("mostra questi record solo se l'utente ha queste capacità "), ... Se la struttura sottostante è cambiata (un campo aggiuntivo che dovrebbe essere preso in considerazione per" validità del record "), abbiamo dovuto cambiare solo una funzione, non venti clausole SQL.

Venivamo da una situazione in cui tutte le clausole SQL (bene, la maggior parte) erano archiviate in un file XML separato, quindi "le modifiche al database sarebbero facili da gestire". Credetemi, non lo erano. Una parte è stata così orribile che ho dovuto presentarlo al Daily WTF .

Se una query era troppo complicata da esprimere con Propel Criteria, o se avevamo bisogno di alcune funzionalità specifiche del fornitore (principalmente la ricerca full-text, dato che stavamo usando MySQL), con Propel non c'era problema. Puoi aggiungere criteri personalizzati o, quando veramente necessario, abbiamo usato il raw SQL ( ora ancora più facile da combinare con gli oggetti Propel reali). Puoi aggiungere facilmente i componenti aggiuntivi specifici del fornitore alle classi generate, in modo da avere il meglio dei due mondi: nessun codice SQL nel codice dell'app, ma con tutte le funzionalità del motore di database.

Ma il punto è che devi programmare lontano dal database, il che significa che non devi pensare come se fossi nel database.

Ora lavoro in C # e uso molto LINQ, quindi molti metodi fluidi. Non ho bisogno di pensare a come i miei oggetti vengono archiviati o trovati, o addirittura salvati a livello di programma e molto poco a livello di business.

Molto spesso i metodi forniti dagli stessi database specifici vengono utilizzati nel connettore DB, quindi si ottengono tali ottimizzazioni senza la necessità di sapere quali sono.

È ancora possibile scrivere funzioni lato DB. Spesso puoi semplicemente mapparli.

E soprattutto, una separazione del genere consente la testabilità e ti costringe (un po ') a scrivere codice strutturato meglio

Gli ORM possono darti accesso anche a funzionalità specifiche del database, dipende da quale ORM stai utilizzando e da quali funzionalità offre.

Ad esempio, nell'attuale progetto a cui sto lavorando, stiamo usando l'API Java Persistence e Hibernate. Tuttavia, utilizziamo diverse funzionalità specifiche del database, come la ricerca in tabelle con soundex.

Per me, il vantaggio principale dell'utilizzo di un ORM non è necessariamente quello di rendere agnostico un database dell'applicazione (anche se è una buona cosa), ma che per la maggior parte non devo pensare a come vengono archiviate e recuperate.

Tuttavia , a un certo punto è molto probabile che tu debba pensarci comunque, a seconda dei requisiti della tua applicazione. L'ORM non è magico.

Ho scritto il mio che mi aiuta a selezionare e inserire più facilmente.

Evey db cosa specifica è disponibile. Devo solo scrivere la query con la quale la libreria mi aiuta (posso usare '?' E params invece di nominare manualmente un parametro e usare .Add)

Immagino che la mia metà faccia schifo a metà utile. Ricevo un po 'di aiuto nel mondo ORM e faccio parti significative nel mondo delle query.

Scrivere codice per inserire e selezionare, aggiornare in linea o con processi memorizzati e mapparli indietro attraverso il DAL è più lungo la norma piuttosto utile solo in casi eccezionali. Gli ORM disponibili, i database di supporto e le lingue la domanda che dovresti porre perché non usi ORM?

Sono standardizzati, universali, specificati o generici. inoltre è più veloce e più facile da implementare. Ho usato subsonic, linq-to-sql e il framework delle entità. Consente allo sviluppatore di concentrarsi sulla logica e sulle regole aziendali anziché sulla mappatura del database.

I miei (semplici) due centesimi:

1: ci sono ORMS e ci sono ORMS. Alcuni ORMS sono basati su Active Record, altri basati su Data Mapper - che di per sé è una considerazione rilevante, ma che richiede alcune indagini per comprendere le implicazioni. In generale, la mia esperienza in PHP è che ORMS supporta il primo, pochi supportano il secondo. Gli ORM basati su Record attivi sembrano avere uno dei due effetti: de-normalizzare il database o invocare una pletora di classi per supportare le interazioni degli oggetti.

2: il vantaggio degli ORM diminuisce in correlazione diretta con la complessità della query che è necessario eseguire. Quando hai una bella relazione semplice, ovvero Utenti -> Post, possono funzionare molto bene. Questo (IMO) è il motivo per cui la maggior parte degli ORM / framework usa esempi come questo. Quando è necessario eseguire query complesse, tuttavia, la quantità di ORMQL che è necessario generare è paragonabile alla lunghezza della stringa di una normale query SQL, ma meno performante a causa del grafico a oggetti che esegue la query che invoca, che tipo di sconfigge il punto di astrazione. Quindi, in breve - gli ORM sono brillanti per il primo 30-50% delle attività del database - ma terribili per l'ultimo. Penso che questo sia un altro motivo per cui l'AR è così diffusa.

3: Perché nascondersi dal database? Utilizzeresti un linguaggio lato server per astrarre javascript?

Personalmente mescolo quegli approcci:

• usa ORM per le basi, caricando "utenti"
• utilizzare un DAO contenente diverse query SQL precotte (ovvero selectLike, selectWhere).
• estendere il DAO ove necessario per aggiungere query personalizzate più specifiche ma riutilizzabili
• Fornire un accesso semplice al database tramite DAO, ovvero $ data = Dao-> query (la stringa sql) per eseguire query una tantum.

Detto questo, Doctrine 2 uscirà presto, il che sembra davvero interessante.

È possibile utilizzare framework di mapper SQL come myBatis se si desidera utilizzare le funzionalità sql.