ORM è un anti-pattern? [chiuso]

C'è una serie piuttosto ampia e variegata di difficoltà concettuali e tecniche quando si prova ad affrontare un database relazionale da un angolo orientato agli oggetti. Queste difficoltà sono note collettivamente come mancata corrispondenza di impedenza relazionale dell'oggetto e articolo Wikipedia relativo è estremamente informativo L'articolo identifica un bel po ', non vedo alcun modo ragionevole di descriverli qui. Solo per darti un'idea generale, sono catalogati come:

• Mismatches
  • Object-oriented concepts
  • Data type differences
  • Structural and integrity differences
  • Manipulative differences
  • Transactional differences
• Solving impedance mismatch
  • Minimization
  • Alternative architectures
  • Compensation
• Contention
• Philosophical differences

Penso che se si prende il tempo di leggere l'articolo capirai che il fatto che l'ORM sia talvolta descritto come un anti-modello è in effetti inevitabile. I due domini sono così diversi che ogni approccio per trattare uno come l'altro è di default un anti-pattern, nel senso che un anti-pattern è un modello che va contro la filosofia di un dominio.

Ma non penso che il termine debba applicarsi a qualsiasi cosa che agisca essenzialmente da ponte tra due domini molto diversi. Etichettare un pattern come anti-pattern ha senso solo all'interno del suo dominio. Quindi la questione se sia un anti-pattern o no è irrilevante.

Ma è utile? Sì, l'ORM è uno degli anti-pattern più utili in circolazione. Capirai perché solo se ti trovi in una situazione pratica in cui dovrai scambiare i database in un progetto. O anche l'aggiornamento ad un'altra versione dello stesso database. ORM è una di quelle cose, che capisci solo quando ne hai effettivamente bisogno.

Ovviamente, come ogni cosa utile, ORM è molto incline all'abuso. Se pensi che in qualche modo sostituisca la necessità di sapere tutto sul database su cui lavori, poi tornerà e ti morderà. Difficile.

Infine, lasciami spudoratamente collegare un'altra delle mie risposte , sul relativo " Il pattern ActiveRecord segue / incoraggia i principi di progettazione SOLID? " domanda, che per me è una domanda molto più pertinente rispetto a" è un anti-pattern ".

Questo è come chiedere "è un trapano elettrico un anti-modello?". Gli ORM hanno guadagnato un buon posto nella mia cassetta degli attrezzi, riducendo il mio codice boilerplate e sono ancora in grado di utilizzare SQL personalizzato, se necessario. Quindi, se si tratta di un anti-modello, quale modello va contro?

La mia risposta è no, ci sono un sacco di ORM maturi là fuori che ti rendono la vita molto più facile e rende il tuo codice più comprensibile. Questo in ogni caso significa che non è necessario comprendere SQL, al contrario.

Vorrei esitare a chiamare qualcosa un "anti-pattern" che è stato inizialmente definito un pattern di Martin Fowler e da allora è stato abbracciato in quasi tutti i linguaggi di programmazione moderni. (Vedi l'articolo di Wikipedia su ActiveRecord .)

Un buon ORM può portare a molto meno codice (e molto meno ripetizioni) in un progetto, e nulla è strongmente correlato con bug come quantità di codice originale.

Gli ORM sono generalmente progettati per gestire i casi d'uso più comuni per lavorare con i database. Le query complesse possono ancora essere scritte esplicitamente. Ma vorrei strongmente scomodare la scrittura di query esplicite per ogni interazione con il database. Nella maggior parte dei casi, è una perdita di tempo.

L'utilizzo di un ORM anziché l'apprendimento di SQL è una pessima idea. Se non si conosce esattamente il tipo di SQL generato, se non si capiscono i problemi N + 1 e come ottimizzare allora causerà sicuramente più danni che benefici. Sento però che sono molto più produttivo usando un ORM. Preferisco Rails ActiveRecord, che non prova a fingere che non ci sia un database e non ti intrometti se hai solo bisogno di scrivere SQL. Tuttavia, temo che alcune persone possano fidarsi degli idiomi che vedono troppo profondamente, senza una profonda comprensione di ciò che stanno facendo.

La mia esperienza: sto usando NHibernate con Linq2NHibernate.

Pro:

• Si sbarazza di "Magic Strings", o almeno offre una volta e una volta una posizione per metterli
• Mi consente di lavorare in un paradigma OO per tutto il tempo
• Il codice è più facile da leggere
• Il codice creato sopra è più facile da cambiare
• Ti permette di scambiare il tuo attuale database relazionale senza dover gestire 2 repository separati (raramente fatto, ma questo è un grande vantaggio se ne hai bisogno).

Contro:

• Il codice è più difficile da scrivere , perché
• Non è un'astrazione sufficiente - devi ancora essere intimamente familiare con ciò che sta facendo in background

Dirò che non è all'altezza della promessa che la maggior parte delle persone inizialmente auspica. Non darei la colpa a qualcuno per aver detto che è un anti-modello. Nel mio caso, trovo che devo ancora eseguire test di integrazione su un database SQLite per assicurarmi che le mie query su Linq2NHibernate funzionino effettivamente. Quindi, in realtà, se stai facendo test di integrazione su un vero database relazionale, allora quel tipo di eliminazione del problema con "stringhe magiche".

Se dovessi iniziare un nuovo progetto, non sono sicuro di utilizzare un ORM o meno. Probabilmente lo farei, ma non posso dire con certezza che tu dovresti. Direi che è come la differenza tra scegliere C ++ o Java / .NET per il tuo progetto: hai bisogno della flessibilità che ottieni lavorando a un livello più basso, o preferiresti lavorare a un livello più alto e (presumibilmente) essere più produttivo? La risposta normale è di lavorare ad un livello così alto che può farcela . Questo di solito significa usare un ORM.

Il punto di forza di un ORM è che consente di modellare il comportamento dell'applicazione utilizzando tecniche orientate agli oggetti. In un mondo attentamente progettato, hai un livello dell'applicazione in cui la lingua del business incontra perfettamente la lingua del team di sviluppo. L'ORM è un attivatore di questo, se l'ORM è usato in modo ragionevole.

Il punto debole è che il numero di persone che realmente, davvero ottengono la programmazione orientata agli oggetti è piuttosto piccolo. Molte persone scrivono spaghetti e polpette, con oggetti altamente accoppiati che hanno un comportamento limitato e il comportamento reale finisce nelle orribili classi "Servizio" e "Manager" di 8000 righe e quel codice è spesso così contorto che tutti hanno paura di cambiarlo perché non riescono a capire quali saranno gli effetti collaterali.

Inoltre, molte persone non ottengono realmente il modello relazionale. Un ORM non li aiuterà a ottenerlo e non li aiuterà estraendo il modello relazionale. Ti consente solo di concentrarti presto sul livello del dominio e farlo correttamente prima di iniziare a preoccuparti troppo della progettazione del database. Se applicato bene, con l'aiuto di strumenti di migrazione degli schemi sensibili, e ORM può aiutarti a prevenire l'accumulo di debito di codice.

Ho sviluppato applicazioni in cui un ORM ha mantenuto il codice dell'applicazione semplice, leggibile e testabile e ha avuto prestazioni ragionevoli. Ho anche mantenuto applicazioni in cui il pattern è stato utilizzato in modo improprio e il codice è stato contorto, non testabile, lento e fragile; si scopre che l'ORM stesso aveva poco a che fare con questo, tranne che invece di scrivere codice cattivo che modellava male il dominio dell'applicazione, il team di ingegneri legacy ha scritto un codice errato che modellava male il dominio dell'applicazione E un cattivo codice del livello di servizio che trascurava tutto il valore che il loro ORM potrebbe fornire loro.

Gli ORM non ti renderanno più intelligenti, ma nelle mani dello sviluppatore giusto, possono portare a un codice più gestibile e di qualità superiore.

Forse la risposta sta nel contrario della tua domanda: memorizzare i dati dell'applicazione in qualcosa di altro di un database relazionale è una buona idea? Quali problemi stai eliminando e quali altri problemi raccoglierai? Riesci a vivere senza la possibilità di fare facilmente riferimenti incrociati ai tuoi dati (join) o filtrare rapidamente i record che desideri in base a più criteri? Non hai bisogno di un solido supporto per le transazioni (supponendo che l'alternativa non ce l'abbia)? Non tutte le applicazioni richiedono un archivio dati sempre coerente e completo.

Penso che il vero anti-pattern qui stia usando un DB relazionale quando non ne hai bisogno. Se ne hai bisogno, allora hai bisogno di ORM, e sicuramente non è un anti-pattern.

ORM è uno strumento. Come tutti gli strumenti, se usati in modo appropriato, funzionano abbastanza bene. Se usato in modo inappropriato, ha bisogno di un martello più grande e del nastro adesivo.

Nel caso del progetto in corso a cui sto lavorando, sarà gestito da non sviluppatori (ingegneri meccanici, per essere precisi) e quindi deve essere semplice e facile da capire. Saranno diversi anni prima che questo gruppo disponga di un budget per assumere sviluppatori (presumendo che il prossimo Presidente non abolisca l'agenzia coinvolta), quindi le capacità di manutenzione futura sono un fattore importante nelle nostre considerazioni.