Dove ORM cadono attraverso?

Question

Mi capita spesso di sentire la gente colpire ORM per essere inflessibile e di una "astrazione che perde", ma davvero non si sente perché Sono problematico. Se usato correttamente, che cosa sono esattamente le colpe di ORM? Mi sto chiedendo questo perché sto lavorando su un PHP ORM e mi piacerebbe per poter risolvere i problemi che un sacco di altri ORM non riescono a, come ad esempio il caricamento pigro e la mancanza di sottoquery.

Si prega di essere specifici con le vostre risposte. Mostra un po 'di codice o descrivere uno schema di database in cui un ORM lotte. Non importa la lingua o l'ORM.

Answer 1

Uno dei problemi più grandi che ho notato con tutti gli ORM che ho usato è l'aggiornamento solo alcuni campi senza recuperare l'oggetto prima.

Ad esempio, dire che ho un oggetto Project mappato nel mio database con i seguenti campi: ID, nome, descrizione, owning_user. Dire, tramite ajax, voglio aggiornare solo il campo di descrizione. Nella maggior parte ORM l'unico modo per me per aggiornare la tabella del database mentre solo con id e descrizione valori è recuperare sia l'oggetto di progetto dal database, impostare la descrizione e quindi inviare la schiena oggetto nel database (richiedendo così due operazioni di database solo per un aggiornamento semplice) o per aggiornare tramite procedure memorizzate (che è il metodo attualmente sto usando).

Answer 2

Gli oggetti e record del database in realtà non sono poi così simili. Essi hanno digitato slot che è possibile memorizzare roba, ma che su di esso. I database hanno una completamente diversa nozione di identità di linguaggi di programmazione. Essi non possono gestire gli oggetti compositi bene, quindi è necessario utilizzare tabelle aggiuntive e chiavi esterne, invece. La maggior parte hanno il concetto di tipo di ereditarietà. E il modo naturale per navigare una rete di oggetti (seguire alcuni dei puntatori in un unico oggetto, ottenere un altro oggetto, e dereferenziare di nuovo) è molto meno efficiente quando mappato al mondo dei database, perché bisogna fare più viaggi di andata e recuperare un sacco dei dati che non ha a cuore.

In altre parole: l'astrazione non può essere fatta molto bene, in primo luogo; non sono gli strumenti ORM che fanno male, ma la metafora che attuano. Invece di un isomorfismo perfetta è solo una somiglianza superficiale, in modo che il compito in sé non è una buona astrazione. (E 'ancora modo più utile che dover comprendere i database intimamente, però. Il disprezzo per strumenti ORM provengono per lo più da amministratori di database guardando verso il basso su semplici programmatori.)

Answer 3

ORM anche in grado di scrivere codice che non è efficiente. Dal momento che le prestazioni del database è fondamentale per la maggior parte dei sistemi, possono causare problemi che avrebbero potuto essere evitate se un essere umano ha scritto il codice (ma che non sarebbe stato meglio se l'uomo in questione non capiva ottimizzazione delle prestazioni del database). Ciò è particolarmente vero quando l'interrogazione diventa complesso.

Credo che il mio più grande problema con loro è però che astraendo via i dettagli, i programmatori juniores sono sempre meno comprensione di come scrivere query che hanno bisogno di essere in grado di gestire i casi limite ed i luoghi in cui l'ORM scrive davvero codice errato. E 'davvero difficile da imparare la roba avanzata quando non hai mai avuto a capire le basi. Un ORM nelle mani di qualcuno che capisce unisce e di gruppo da parte e l'interrogazione avanzata è una buona cosa. Nelle mani di qualcuno che non capisce l'algebra booleana e si unisce e un mucchio di altri concetti di base di SQL, è una pessima cosa con conseguente molto cattiva progettazione del database e le query.

I database relazionali non sono oggetti e non deve essere trattato come tale. Cercando di fare un'aquila in una borsa di seta non è generalmente efficace. Molto meglio per imparare ciò che l'aquila è bravo e perché e lascia volare un'aquila che avere una cattiva borsa e un'aquila morto.

Answer 4

Il mio modo di vedere è come questo. Per usare un ORM, si deve di solito pila diverse funzioni PHP, e quindi connettersi a un database ed essenzialmente ancora esegue una query MySQL o qualcosa di simile.

Perché tutti l'astrazione tra il codice e il database? Perché non possiamo semplicemente usare quello che già sappiamo? In genere uno sviluppatore web conosce la loro lingua back-end, la loro lingua db (una sorta di SQL), e una sorta di lingue frontend, come HTML, CSS, JS, etc ...

In sostanza, stiamo cercando di aggiungere uno strato di astrazione che comprende molte funzioni (e abbiamo tutte le funzioni PHP sa può essere più lento di assegnazione di una variabile). Sì, questo è un micro calcolo, ma ancora, si aggiunge.

Non solo abbiamo ora hanno diverse funzioni per passare attraverso, ma dobbiamo anche imparare il modo in cui le opere ORM, quindi c'è un po 'di tempo sprecato lì. Ho pensato che l'intera idea di separazione tra il codice è stato quello di mantenere il vostro codice separato a tutti i livelli. Se sei nel mondo LAMP, basta creare la query (si dovrebbe sapere MySQL) e utilizzare la funzione php già esistente per le istruzioni preparate. FATTO!

LAMP WAY:

• creare query (stringa);
• uso mysqli istruzioni preparate e recuperare i dati in una matrice.

ORM WAY:

• eseguire una funzione che ottiene l'entità
• che gestisce un MySQL Query
• eseguire un'altra funzione che aggiunge un condizionale
• eseguire un'altra funzione che aggiunge un altro condizionale
• eseguire un'altra funzione che unisce
• eseguire un'altra funzione che aggiunge condizionali sul join
• eseguire un'altra funzione che prepara
• corre un altro MySQL Query
• eseguire un'altra funzione che recupera i dati
• corre un altro MySQL Query

Qualcun altro ha un problema con la pila ORM? Perché stiamo diventando tali sviluppatori pigri? O almeno così creativa che stiamo danneggiando il nostro codice? Se non è rotto non aggiustarlo. A sua volta, fissare il vostro team di sviluppo per capire le basi del web dev.

Answer 5

ORM sta tentando di risolvere un problema molto complesso. Ci sono casi bordo bizzeffe e grandi compromessi di design con soluzioni chiare e ovvie. Quando si ottimizza un design ORM per la situazione di A, è intrinsecamente rendono scomodo per risolvere la situazione B.

Ci sono ORM che gestiscono il caricamento pigro e subquery in modo "abbastanza buono", ma è quasi impossibile ottenere da "abbastanza buono" per "grande".

Nel progettare il vostro ORM, si deve avere un bel manico bene su tutte le possibili banca dati imbarazzante disegna il vostro ORM sarà chiamato a maniglia. Devi fare in modo esplicito compromessi intorno a cui le situazioni si è disposti a gestire maldestramente.

Non guardare ORM come inflessibile o più incapace di ritenere che il vostro astrazione media complessa. Detto questo, alcune ORM sono meglio di altri in questi aspetti.

Buona fortuna reinventare la ruota.