Perché tutti gli Active Record odiano? [chiuso]

Man mano che imparo sempre di più su OOP e inizio a implementare vari modelli di progettazione, continuo a tornare a casi in cui le persone odiano su Active Record .

Spesso le persone dicono che non si adatta bene (citando Twitter come primo esempio), ma nessuno spiega effettivamente perché non si adatta bene; e / o come ottenere i vantaggi dell'AR senza i contro (tramite un modello simile ma diverso?)

Spero che questa non si trasformi in una guerra santa sui modelli di design - tutto quello che voglio sapere è **** specificamente **** cosa c'è di sbagliato in Active Record.

Se non scala bene, perché no?

Quali altri problemi ha?

Ci sono ActiveRecord the Design Pattern e ActiveRecord the Rails ORM Library , e ci sono anche un sacco di knock-off per .NET e altri linguaggi.

Sono tutte cose diverse. Per lo più seguono quel modello di progettazione, ma lo estendono e lo modificano in molti modi diversi, quindi prima che qualcuno dica "ActiveRecord Sucks" deve essere qualificato dicendo "quale ActiveRecord, ci sono cumuli?"

Conosco solo ActiveRecord di Rails, cercherò di risolvere tutti i reclami che sono stati sollevati nel contesto dell'utilizzo.

@BlaM

Il problema che vedo con Active Records è che si tratta sempre di una sola tabella

Codice:

class Person
    belongs_to :company
end
people = Person.find(:all, :include => :company )

Questo genera SQL con LEFT JOIN companies on companies.id = person.company_ide genera automaticamente gli oggetti Company associati in modo che tu possa fare people.first.companye non è necessario colpire il database perché i dati sono già presenti.

@ pix0r

Il problema intrinseco con Active Record è che le query di database vengono generate ed eseguite automaticamente per popolare gli oggetti e modificare i record del database

Codice:

person = Person.find_by_sql("giant complicated sql query")

Questo è scoraggiato perché è brutto, ma per i casi in cui devi semplicemente scrivere un SQL grezzo, è facile.

@Tim Sullivan

... e selezioni diverse istanze del modello, in pratica stai facendo un "seleziona * da ..."

Codice:

people = Person.find(:all, :select=>'name, id')

Questo selezionerà solo il nome e le colonne ID dal database, tutti gli altri "attributi" negli oggetti mappati saranno semplicemente nulli, a meno che non si ricarichi manualmente quell'oggetto e così via.

Ho sempre trovato che ActiveRecord è buono per applicazioni rapide basate su CRUD in cui il modello è relativamente piatto (come in, non molte gerarchie di classi). Tuttavia, per le applicazioni con complesse gerarchie OO, un DataMapper è probabilmente una soluzione migliore. Sebbene ActiveRecord presupponga un rapporto 1: 1 tra le tabelle e gli oggetti dati, quel tipo di relazione diventa ingombrante con domini più complessi. Nel suo libro sui modelli , Martin Fowler sottolinea che ActiveRecord tende a rompersi in condizioni in cui il tuo modello è abbastanza complesso e suggerisce un DataMapper come alternativa.

Ho scoperto che ciò è vero nella pratica. Nei casi in cui hai molta eredità nel tuo dominio, è più difficile mappare l'ereditarietà al tuo RDBMS piuttosto che mappare associazioni o composizione.

Il modo in cui lo faccio è avere oggetti "dominio" a cui si accede dai controller tramite queste classi DataMapper (o "livello di servizio"). Questi non rispecchiano direttamente il database, ma fungono da rappresentazione OO per alcuni oggetti del mondo reale. Supponiamo che tu abbia una classe User nel tuo dominio e che sia necessario avere riferimenti a, o raccolte di altri oggetti, già caricati quando recuperi quell'oggetto User. I dati possono provenire da molte tabelle diverse e un pattern ActiveRecord può renderlo davvero difficile.

Invece di caricare direttamente l'oggetto User e accedere ai dati utilizzando un'API in stile ActiveRecord, il codice del controller recupera un oggetto User chiamando l'API del metodo UserMapper.getUser (), ad esempio. È quel mapper che è responsabile del caricamento di qualsiasi oggetto associato dalle rispettive tabelle e della restituzione dell'oggetto "dominio" Utente completato al chiamante.

In sostanza, stai semplicemente aggiungendo un altro livello di astrazione per rendere il codice più gestibile. Se le tue classi DataMapper contengono SQL personalizzato grezzo, o chiamate a un'API del livello di astrazione dei dati, o addirittura accedono a un pattern ActiveRecord, non ha molta importanza per il codice del controller che sta ricevendo un oggetto utente carino e popolato.

Comunque, è così che lo faccio.

Penso che ci sia probabilmente una serie di ragioni molto diverse tra il motivo per cui le persone "odiano" su ActiveRecord e cosa c'è di "sbagliato" in esso.

Sulla questione dell'odio, c'è molto veleno nei confronti di tutto ciò che riguarda Rails. Per quanto riguarda ciò che non va, è probabile che sia come tutta la tecnologia e ci sono situazioni in cui è una buona scelta e situazioni in cui ci sono scelte migliori. La situazione in cui non puoi sfruttare la maggior parte delle funzionalità di Rails ActiveRecord, secondo la mia esperienza, è dove il database è strutturato male. Se si accede ai dati senza chiavi primarie, con cose che violano la prima forma normale, dove sono necessarie molte procedure memorizzate per accedere ai dati, è meglio usare qualcosa che è più di un semplice wrapper SQL. Se il tuo database è relativamente ben strutturato, ActiveRecord ti consente di trarne vantaggio.

Da aggiungere al tema della risposta ai commentatori che dicono che le cose sono difficili in ActiveRecord con una controreplica di frammenti di codice

@Sam McAfee Supponiamo che tu abbia una classe Utente nel tuo dominio e che sia necessario avere riferimenti a, o raccolte di altri oggetti, già caricati quando recuperi quell'oggetto Utente. I dati possono provenire da molte tabelle diverse e un pattern ActiveRecord può renderlo davvero difficile.

user = User.find(id, :include => ["posts", "comments"])
first_post = user.posts.first
first_comment = user.comments.first

Utilizzando l'opzione include, ActiveRecord consente di ignorare il comportamento di caricamento lento predefinito.

La mia risposta lunga e tardiva, nemmeno completa, ma una buona spiegazione PERCHÉ odio questo schema, opinioni e persino alcune emozioni:

1) versione breve: Active Record crea un " sottile strato " di " legame forte " tra il database e il codice dell'applicazione. Che non risolve nessun problema logico, nessun problema, nessun problema. IMHO non fornisce NESSUN VALORE, tranne un po 'di zucchero sintattico per il programmatore (che può quindi utilizzare una "sintassi oggetto" per accedere ad alcuni dati, che esiste in un database relazionale). Lo sforzo per creare un po 'di conforto per i programmatori dovrebbe (IMHO ...) meglio essere investito in strumenti di accesso al database di basso livello, ad esempio alcune variazioni di hash_map get_record( string id_value, string table_name, string id_column_name="id" )metodi semplici, facili, semplici e simili (ovviamente, i concetti e l'eleganza variano notevolmente con il lingua utilizzata).

2) versione lunga: in qualsiasi progetto basato su database in cui avevo il "controllo concettuale" delle cose, ho evitato l'AR, ed è stato un bene. Di solito costruisco un'architettura a strati (prima o poi dividi il tuo software in strati, almeno in progetti di dimensioni medio-grandi):

A1) il database stesso, le tabelle, le relazioni, anche un po 'di logica se il DBMS lo consente (anche MySQL è cresciuto ora)

A2) molto spesso, c'è più di un archivio dati: file system (i blob nel database non sono sempre una buona decisione ...), sistemi legacy (immagina te stesso "come" si accederà, molte varietà possibili .. ma questo è non è il punto ...)

B) livello di accesso al database (a questo livello, i metodi degli strumenti, gli helper per accedere facilmente ai dati nel database sono molto graditi, ma AR non fornisce alcun valore qui, tranne un po 'di zucchero sintattico)

C) livello degli oggetti dell'applicazione: gli "oggetti dell'applicazione" a volte sono semplici righe di una tabella nel database, ma la maggior parte delle volte sono comunque oggetti composti e hanno una logica più elevata collegata, quindi investire tempo in oggetti AR a questo livello è semplicemente inutile , una perdita di tempo prezioso per i programmatori, perché il "valore reale", la "logica superiore" di quegli oggetti deve essere implementato in cima agli oggetti AR, comunque - con e senza AR! E, ad esempio, perché si desidera avere un'astrazione di "Oggetti voce di registro"? Il codice logico dell'app li scrive, ma dovrebbe essere in grado di aggiornarli o eliminarli? sembra sciocco, ed App::Log("I am a log message")è più facile da usare di alcune grandezze rispetto ale=new LogEntry(); le.time=now(); le.text="I am a log message"; le.Insert();. E ad esempio: l'utilizzo di un "Oggetto voce di registro" nella vista registro nella tua applicazione funzionerà per 100, 1000 o anche 10000 righe di registro, ma prima o poi dovrai ottimizzare - e scommetto che nella maggior parte dei casi, dovrai solo usa quella piccola e bellissima istruzione SQL SELECT nella logica della tua app (che rompe totalmente l'idea AR ..), invece di racchiudere quella piccola istruzione in frame di idee AR fissi rigidi con un sacco di codice che avvolge e nasconde. Il tempo sprecato con la scrittura e / o la creazione di codice AR avrebbe potuto essere investito in un'interfaccia molto più intelligente per leggere elenchi di voci di registro (molti, molti modi, il cielo è il limite). I programmatori dovrebbero osare inventare nuove astrazioni per realizzare la loro logica applicativa che si adatta all'applicazione prevista e non reimplementare stupidamente schemi stupidi, che suona bene a prima vista!

D) la logica dell'applicazione: implementa la logica dell'interazione degli oggetti e della creazione, eliminazione e elenco (!) Di oggetti della logica dell'applicazione (NO, queste attività raramente dovrebbero essere ancorate negli oggetti della logica dell'applicazione stessa: il foglio di carta sulla scrivania lo dice hai i nomi e le posizioni di tutti gli altri fogli nel tuo ufficio? dimentica i metodi "statici" per elencare gli oggetti, è sciocco, un pessimo compromesso creato per far sì che il modo di pensare umano si adatti a [alcuni non tutti-AR-framework-like -] Pensiero AR)

E) l'interfaccia utente - beh, quello che scriverò nelle righe seguenti è molto, molto, molto soggettivo, ma nella mia esperienza, i progetti basati su AR spesso trascuravano la parte dell'interfaccia utente di un'applicazione - il tempo era sprecato per creare astrazioni oscure . Alla fine tali applicazioni hanno sprecato molto tempo ai programmatori e sembrano applicazioni da programmatori per programmatori, inclini alla tecnologia dentro e fuori. I programmatori si sentono bene (duro lavoro finalmente fatto, tutto finito e corretto, secondo il concetto sulla carta ...), e i clienti "devono solo imparare che deve essere così", perché questo è "professionale" .. ok, scusa, sto divagando ;-)

Certo, tutto questo è soggettivo, ma è la mia esperienza (escluso Ruby on Rails, potrebbe essere diverso, e non ho esperienza pratica con questo approccio).

Nei progetti a pagamento, ho spesso sentito la richiesta di iniziare con la creazione di alcuni oggetti "record attivi" come elementi costitutivi per la logica dell'applicazione di livello superiore. Nella mia esperienza, questo è molto spessoera una sorta di scusa per il fatto che il cliente (una società di sviluppo di software nella maggior parte dei casi) non aveva una buona idea, una visione d'insieme, una panoramica di ciò che il prodotto dovrebbe essere finalmente. Quei clienti pensano in strutture rigide ("nel progetto dieci anni fa ha funzionato bene .."), possono arricchire le entità, possono definire relazioni tra entità, possono scomporre le relazioni di dati e definire la logica di base dell'applicazione, ma poi si fermano e consegnalo a te, e pensa che sia tutto ciò di cui hai bisogno ... spesso mancano di un concetto completo di logica dell'applicazione, interfaccia utente, usabilità e così via e così via ... mancano di una visione d'insieme e non amano dettagli, e vogliono che tu segua quel modo di fare AR, perché .. beh, perché, ha funzionato in quel progetto anni fa, tiene le persone occupate e silenziose? Non lo so. Ma i "dettagli" separare gli uomini dai ragazzi, o .. com'era lo slogan pubblicitario originale? ;-)

Dopo molti anni (dieci anni di esperienza di sviluppo attivo), ogni volta che un cliente menziona uno "schema di registrazione attivo", il mio campanello d'allarme suona. Ho imparato a cercare di riportarli a quella fase concettuale essenziale , farli riflettere due volte, provarli a mostrare le loro debolezze concettuali o semplicemente evitarli del tutto se non hanno discernimento (alla fine, sai, un cliente che non lo fa ancora sa quello che vuole, forse pensa anche di sapere ma non lo fa, o cerca di esternalizzare gratuitamente il lavoro di concetto a ME, mi costa molte ore, giorni, settimane e mesi preziosi del mio tempo, vivere è troppo breve ...).

Quindi, finalmente: QUESTO è il motivo per cui odio quello stupido "schema di registrazione attivo", e lo faccio e lo eviterò quando possibile.

EDIT : lo chiamerei anche No-Pattern. Non risolve alcun problema (i modelli non sono pensati per creare zucchero sintattico). Crea molti problemi: la radice di tutti i suoi problemi (menzionati in molte risposte qui ..) è che nasconde solo il buon vecchio SQL ben sviluppato e potente dietro un'interfaccia che è estremamente limitata dalla definizione dei modelli.

Questo modello sostituisce la flessibilità con lo zucchero sintattico!

Pensaci, quale problema ti risolve l'AR?

Alcuni messaggi mi stanno confondendo. Alcune risposte stanno andando a "ORM" vs "SQL" o qualcosa del genere.

Il fatto è che AR è solo un modello di programmazione di semplificazione in cui si trae vantaggio dagli oggetti del dominio per scrivere lì il codice di accesso al database.

Questi oggetti di solito hanno attributi aziendali (proprietà del bean) e alcuni comportamenti (metodi che di solito funzionano su queste proprietà).

L'AR dice semplicemente "aggiungi alcuni metodi a questi oggetti di dominio" alle attività relative al database.

E devo dire, dalla mia opinione ed esperienza, che non mi piace lo schema.

A prima vista può suonare abbastanza bene. Alcuni strumenti Java moderni come Spring Roo utilizzano questo modello.

Per me, il vero problema è solo con la preoccupazione OOP. Il modello AR ti obbliga in qualche modo ad aggiungere una dipendenza dal tuo oggetto agli oggetti dell'infrastruttura. Questi oggetti dell'infrastruttura consentono all'oggetto dominio di interrogare il database attraverso i metodi suggeriti da AR.

Ho sempre detto che due livelli sono la chiave per il successo di un progetto. Il livello di servizio (dove risiede la logica di business o può essere esportato attraverso un qualche tipo di tecnologia remota, come i servizi Web, per esempio) e il livello di dominio. A mio parere, se aggiungiamo alcune dipendenze (non realmente necessarie) agli oggetti del livello di dominio per risolvere il pattern AR, i nostri oggetti di dominio saranno più difficili da condividere con altri livelli o applicazioni esterne (rare).

L'implementazione Spring Roo di AR è interessante, perché non si basa sull'oggetto stesso, ma su alcuni file AspectJ. Ma se in seguito non vuoi lavorare con Roo e devi rifattorizzare il progetto, i metodi AR verranno implementati direttamente negli oggetti del tuo dominio.

Un altro punto di vista. Immagina di non utilizzare un database relazionale per memorizzare i nostri oggetti. Immagina che l'applicazione memorizzi i nostri oggetti di dominio in un database NoSQL o solo in file XML, ad esempio. Implementeremmo i metodi che svolgono queste attività nei nostri oggetti di dominio? Non credo (ad esempio, nel caso di XM, aggiungeremmo dipendenze relative a XML ai nostri oggetti di dominio ... Veramente triste penso). Perché allora dobbiamo implementare i metodi DB relazionali negli oggetti del dominio, come dice il pattern Ar?

Per riassumere, il pattern AR può sembrare più semplice e buono per applicazioni piccole e semplici. Ma, quando abbiamo app complesse e di grandi dimensioni, penso che la classica architettura a strati sia un approccio migliore.

La domanda riguarda il design pattern di Active Record. Non è uno strumento ormonale.

La domanda originale è contrassegnata con rails e si riferisce a Twitter che è costruito in Ruby on Rails. Il framework ActiveRecord all'interno di Rails è un'implementazione del modello di progettazione Active Record di Fowler.

La cosa principale che ho visto riguardo ai reclami su Active Record è che quando crei un modello attorno a un tavolo e selezioni diverse istanze del modello, in pratica stai facendo una "selezione * da ...". Questo va bene per modificare un record o visualizzare un record, ma se vuoi, ad esempio, visualizzare un elenco delle città per tutti i contatti nel tuo database, puoi fare "seleziona Città da ..." e ottenere solo le città . Fare ciò con Active Record richiederebbe la selezione di tutte le colonne, ma solo l'utilizzo di City.

Ovviamente, diverse implementazioni gestiranno questo in modo diverso. Tuttavia, è un problema.

Ora puoi aggirare questo problema creando un nuovo modello per la cosa specifica che stai cercando di fare, ma alcune persone sostengono che è più uno sforzo che un vantaggio.

Io adoro Active Record. :-)

HTH

Adoro il modo in cui SubSonic fa l'unica cosa della colonna.
O

DataBaseTable.GetList(DataBaseTable.Columns.ColumnYouWant)

, o:

Query q = DataBaseTable.CreateQuery()
               .WHERE(DataBaseTable.Columns.ColumnToFilterOn,value);
q.SelectList = DataBaseTable.Columns.ColumnYouWant;
q.Load();

Ma Linq è ancora il re quando si tratta di caricamento lento.

@ BlaM: a volte ho implementato un record attivo per il risultato di un join. Non deve sempre essere la relazione Table <--> Active Record. Perché non "Risultato di un'istruzione Join" <--> Active Record?

Parlerò di Active Record come design pattern, non ho visto ROR.

Alcuni sviluppatori odiano Active Record, perché leggono libri intelligenti sulla scrittura di codice pulito e ordinato, e questi libri affermano che il record attivo viola il singolo principio di resposobilità, viola la regola DDD che l'oggetto del dominio dovrebbe essere persistente ignorante e molte altre regole da questo tipo di libri .

La seconda cosa che gli oggetti di dominio in Active Record tendono ad essere 1-a-1 con il database, che può essere considerato una limitazione in alcuni tipi di sistemi (principalmente n-tier).

Queste sono solo cose astratte, non ho visto ruby ​​on rails l'effettiva implementazione di questo pattern.

Il problema che vedo con Active Records è che si tratta sempre di una sola tabella. Va bene, fintanto che lavori davvero solo con quella tabella, ma quando lavori con i dati nella maggior parte dei casi avrai una sorta di join da qualche parte.

Sì, il join di solito è peggio di nessun join quando si tratta di prestazioni, ma unirsi di solito è meglio di un join "falso" leggendo prima l'intera tabella A e quindi utilizzando le informazioni ottenute per leggere e filtrare la tabella B.

Il problema con ActiveRecord è che le query che genera automaticamente possono causare problemi di prestazioni.

Finisci per fare alcuni trucchi non intuitivi per ottimizzare le query che ti lasciano chiedersi se sarebbe stato più efficace scrivere la query a mano in primo luogo.

Sebbene tutti gli altri commenti sull'ottimizzazione SQL siano certamente validi, la mia lamentela principale con il modello di registrazione attivo è che di solito porta a un disadattamento di impedenza . Mi piace mantenere il mio dominio pulito e adeguatamente incapsulato, cosa che il pattern di registrazione attivo di solito distrugge ogni speranza di fare.

Prova a creare una relazione polimorfica molti a molti. Non così semplice. Soprattutto quando non stai usando STI.