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

Lo vedo allo stesso modo. Qualsiasi astrazione che non ti permetta di entrare al di sotto di essa quando è necessario è malvagia, perché porta a tutti i tipi di brutte inversioni di astrazione nel tuo codice.

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

IMO qualsiasi ORM che non ha questa caratteristica non vale i bit da cui è stato compilato.

the ORM takes the lowest common denominator

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

Nota rapida: si cita solo l'astrazione del database. Questo è uno dei molti vantaggi, ma penso davvero che le caratteristiche orientate agli oggetti siano più potenti (es: ereditarietà). E You design your domain model first ...

... Torna all'astrazione. Non è il minimo comune denominatore. In nHibernate hai dialetti. Ti permette di usare uno stesso codice per interrogare diversi database. I dialetti si prendono cura 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 .

Come esempio prendi il dialetto SqlServer2005 che, una volta introdotto, traeva vantaggio dalle nuove funzionalità di paging di SQL Server 2005. L'uso di quel dialetto invece di SqlServer2000 ha semplicemente aumentato le tue prestazioni.

Naturalmente ci sono delle eccezioni, ma non ho incontrato nessuno 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. Non è stato un problema per me scrivere da solo l'SQL (o gestire qualunque spazio di archiviazione sia usato). Ma, ho il lusso di lavorare su un numero minore di progetti con vite di prodotto più lunghe, quindi una volta che la manipolazione SQL e DB codificata a mano è a posto, è a posto. Inoltre, ovviamente, puoi 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 entrare in una di esse:

Sei effettivamente che guadagna qualcosa dall'usarli? Cioè, stai risparmiando una quantità sufficiente di sforzi implementando uno strumento ORM per farlo valere la pena di usare, e per fare in modo che valga la pena aggiungere una complicazione extra al tuo sistema? (Questo è particolarmente vero per le app commerciali, dove quel "pezzo" extra è ora un vettore extra per potenziali problemi di supporto)

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

O / R-M è stato criticato regolarmente. Ted Neward lo ha definito " Vietnam of Computer Science " a qualche anno fa. O / R-M

starts well, gets more complicated as time passes, and before long entraps its users in a commitment that has no clear demarcation point, no clear win conditions, and no clear exit strategy.

A meno che non si scriva solo una propria mappatura ad hoc (che è una buona soluzione in molti casi, come altri hanno già detto), si potrebbero esaminare alternative come l'uso di un database non relazionale. Alcuni dicono che un vero database di oggetti è migliore, altre parole d'ordine menzionate in questo contesto sono LINQ, Ruby e Tutorial D. Suppongo che, al contrario di veri e propri database relazionali, esistano veramente dei database di oggetti. Ma in pratica ho scoperto che la modellazione concettuale dei dati - ovvero scoprire quali oggetti del mondo reale si desidera memorizzare dati e come questi oggetti si relazionano tra loro - è più importante che si debba capire come esprimere il proprio modello concettuale in qualsiasi linguaggio di programmazione o database.

Qual è l'alternativa?

Questa è una nozione interessante. Estrapolando le funzionalità del database sottostante, perdiamo sicuramente alcune delle funzionalità dell'implementazione specifica del database. (Se dipendiamo o meno da specifiche funzionalità del database è un altro argomento) Immagino che questo possa essere risolto da ORM specifici del database che ti permettono di accedere alle funzionalità specifiche, ma che potrebbero essere più problemi di quanto valga e un passo nel direzione sbagliata.

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

Dovremmo smettere di usare gli ORM e tornare a scrivere tutti gli accessi al database da soli? Certo, potremmo perdere l'accesso ad alcune funzionalità del database tramite l'ORM, ma puoi sempre accedere a quelle che utilizzano tecniche di vecchia scuola. Alla fine i guadagni che ottieni in produttività superano di gran lunga gli svantaggi.

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

Tutto ciò che fa un ORM, puoi replicare con Views, Trigger e Stored Procedure. Aiutano a sottrarre SQL raw e mantenere coerenti i database normalizzati. Ma funziona bene solo per casi semplici. Se ci sono troppi dati di processo da processare, possono diventare un drenaggio delle prestazioni. (Gli ORM in PHP spesso prendono il lato di script dei dati, perché le catene dei builder SQL non possono astrarre tutto.)

Ma come al solito, tutto dipende dall'applicazione e dall'attività in corso.

Una cosa che fa male usare gli ORM è che molti dei loro fan tendono a sostenere che non abbiamo più bisogno di conoscere la teoria SQL e RDB. I risultati variano da divertenti a assolutamente catastrofici. E questo nonostante il milione di volte che ORM 'produce e commenta che noi dobbiamo conoscere la teoria di SQL e RDB bene per usare e configurare correttamente un ORM.

Perché le persone prendono uno strumento che ha il suo uso su molti, ma non tutti i contesti in un proiettile d'argento magico, universalmente applicabile è oltre me.

L'anno scorso ho lavorato a un'app interna che è cambiata di frequente, e sono stato molto felice di aver utilizzato un ORM. L'app era un'app di supporto per un team di gestione del cambiamento e con l'evolversi del progetto più grande, la nostra piccola app ha ottenuto nuovi requisiti per situazioni che non esistevano e che non potevano essere previste pochi mesi prima.

Grazie all'ORM ( Propel , in PHP), abbiamo diviso parte della logica per il codice, quindi è stata aggiunta una funzione 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 " record validità "), abbiamo solo dovuto cambiare una funzione, non venti clausole SQL.

Siamo venuti da una situazione in cui tutte le (anche, molte) clausole SQL erano memorizzate in un file XML separato, quindi "le modifiche al database sarebbero facili da gestire". Credimi, non lo erano. Una parte è stata così orribile che ho ha dovuto inviarlo a The Daily WTF .

Se una query era troppo complicata per esprimere con i criteri Propel, o avevamo bisogno di alcune caratteristiche specifiche del fornitore (per lo più ricerca full-text, dato che stavamo usando MySQL), questo non era un problema con Propel. Puoi aggiungere criteri personalizzati , o quando veramente necessario abbiamo usato SQL raw (< a href="http://propel.posterous.com/propel-154-released"> ora è ancora più facile combinare con oggetti Propel effettivi). Puoi facilmente aggiungere i componenti aggiuntivi specifici del fornitore alle classi generate, in modo da avere il meglio di entrambi i mondi: nessun codice SQL nel codice dell'app, ma con tutte le funzionalità del tuo 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 e molti metodi fluenti. Non ho bisogno di pensare a come i miei oggetti sono archiviati o trovati, o addirittura salvati a livello di programma, e molto poco a livello di livello aziendale.

Molto spesso i metodi forniti dai database specifici stessi sono usati nel connettore DB, quindi ottieni quelle ottimizzazioni senza bisogno di sapere quali sono.

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

E soprattutto, la separazione come quella consente la testabilità e ti costringe (poco) a scrivere un codice meglio strutturato

Gli ORM possono consentire anche l'accesso a funzioni specifiche del database, dipende da quale ORM si sta utilizzando e dalle funzionalità fornite.

Per un esempio, nel progetto corrente su cui sto lavorando, stiamo utilizzando Java Persistence API e Hibernate. Anche così, utilizziamo diverse funzionalità specifiche del database, come la ricerca nelle tabelle con soundex.

Per me, il vantaggio principale dell'uso di un ORM non è necessariamente quello di rendere agnostico un database delle applicazioni (anche se è una buona cosa), ma per la maggior parte non devo pensare a come le cose sono memorizzati e recuperati.

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 specifica è disponibile. Devo solo scrivere la query da sola con la libreria (posso usare '?' E params invece di nominare manualmente un parametro e usare .Add)

Credo che il mio mezzo faccia schifo mezzo utile. Ho un aiuto nel mondo ORM e faccio parti significative nel mondo delle query.

Scrivere codice per inserire e selezionare, aggiornare in linea o con proc memorizzati e mapparli indietro attraverso il DAL è più lungo della norma, ma solo vantaggioso nel caso eccezionale. Gli ORM disponibili, i database e le lingue di supporto la domanda che dovresti chiedere perché non stai usando ORM?

Sono standardizzati, universali, specificati o generici. inoltre è più veloce e più facile da implementare. Ho usato subsonic, linq-to-sql e il framework di entità. Permette allo sviluppatore di concentrarsi sulla logica e sulle regole aziendali, invece 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 gli ORMS supportano il primo, pochi supportano quest'ultimo. Gli ORM basati su record attivi sembrano avere uno di questi due effetti: o de-normalizzano il database o invocano una pletora di classi per supportare le interazioni tra oggetti.

2: Il vantaggio degli ORM diminuisce in correlazione diretta con la complessità della query che è necessario eseguire. Quando hai una bella relazione semplice - cioè gli utenti - > Post, possono funzionare molto bene. Questo (IMO) è il motivo per cui la maggior parte degli ORM / framework utilizza esempi come questo. Quando è necessario eseguire query complesse, tuttavia, la quantità di ORMQL che è necessario generare è paragonabile alla lunghezza della stringa di una query SQL regolare, ma meno performante a causa del richiamo del grafo dell'oggetto che esegue la query, che sconfigge il punto di astrazione. Quindi, in poche parole, 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ì diffuso.

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

Personalmente mescolo questi approcci:

• usa ORM per le basi, caricando "utenti"
• usa un DAO contenente diverse query SQL pre-cagliate (ad esempio selectLike, selectWhere).
• estendi il DAO dove necessario per aggiungere query personalizzate più specifiche ma riutilizzabili
• Fornire un accesso semplice al database tramite DAO, ad esempio $ data = Dao- > query (la stringa sql) per eseguire una query.

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

Puoi usare framework SQL mapper come myBatis se vuoi utilizzare le funzionalità sql.