Gitbaritalian
developer
podcast
8

Orm: Datamapper and Active records. Programmazione della persistenza!

Serie 1
Episodio 8
Durata 32 minuti

Ogni applicazione che noi realizziamo ha bisogno di tenere conto della persistenza, abbiamo iniziato la nostra esperienza con la programmazioneinserendo delle query in "RAW SQL" nel nostro codice sorgente ma presto ci siamo resi conto che mischiare i linguaggi, nel mio caso php e sql, non era una cosa buona e giusta quindi abbiamo attinto dal mondo dei pattern e di siamo trovati davanti agli ORM, object relation mapper confondendoci alla vista di active records e data mapper.

Esiste un modo migliore degli altri per effettuare il salvataggio dei nostri dati, se si in che contesto. Questa puntata è un piccolo viaggio con delle sorprese.

#Capitoli

0:00 Saluti iniziali

4:31 I pattern di programmazione

5:35 La persistenza

8:26 Gli ORM

13:29 Active Record

20:25 Data Mapper

25:54 Quale è il miglior approccio

29:37 Saluti finali

#Contatti @brainrepo su twitter o via mail a info@gitbar.it

#Crediti Le sigle sono state prodotte da MondoComputazionale Registrato negli studi di Radio Nuoro Centrale Le musiche da Blan Kytt - RSPN

Trascrizione

Trascrizione automatica realizzata con servizi Amazon AWS Transcribe

benvenuti su Bar, il podcast dedicato al mondo dei developer.
In mezzo artigiani in mezzo artisti che ogni giorno infilavano le mani nel fango per creare nel modo più efficace possibile quei prodotti digitali che quotidianamente utilizzando tu.
Eccoci qua.
Ottava puntata di Mario sono Aleppo e anche oggi vi accompagno in uno di quelli che sono gli argomenti del mondo dei developer.
Ma prima di farlo voglio darvi un'anticipazione ormai passato un mese e mezzo da quando sono partito con questo podcast e quindi sento già le esigenza di proporvi qualcosa di nuovo, qualcosa di fresco e qualcosa di diverso per cui sto ragionando sulla possibilità di fare delle dirette e Twitch diretta e questo non delle sessioni di life coaching dove apriro' la pistola e iniziero' a fare qualcosa.
Io spero possano piacervi.
Cosa andro' a fare in queste dirette nella prima sessione di lei fu di Mi piacerebbe iniziare con voi a lavorare su un nuovo sito di bar.
Ho già qualche idea in realtà sia sulla funzionalità che su come deve essere esteticamente, per cui apriro' appunto lei di torre inizierò a scrivere quali sono le tecnologie che andremo a usare per questo sito? Beh, mi interessa fare un sito statico.
Mi sembrerà strano sentirmi parlare in questo modo, ma fondamentalmente il nostro, fondamentalmente il sito per il podcast e non ha bisogno di avere un bel il essere configurabile, ma semplicemente basta che mostri gli episodi con le note, la possibilità di ascoltare la possibilità di iscriversi al podcast e i contenuti aggiuntivi, quindi sono semplicemente dei calderoni, dei contenitori, gli contenuti scusate la cacofonia.
Per farlo ho pensato di utilizzare il software in, che permette la generazione di pagine statiche contempli hite a partire da una serie di documenti che possono essere march down e quindi va a generare il nostro sito che poi andremo ad approdare.
Ancora non ho deciso se la super chip che ho comprato opposte penso sia piu' che sufficiente, oppure che se ha direttamente su un bucket se tre di Amazon e di lì poi e la diciamo aggiornarlo, sempre a corredo della realizzazione del sito e' mia intenzione andare a fare una serie di sessioni di coding dove vado a realizzare uno strumento che mi sarà molto utile e poi per la la gestione del podcast, per esempio, uno strumento che mi permetta di fare con lanciando un solo comando il transcript della puntata, cosa che per poterlo fare oggi devo aprile amazon entrare nei servizi aws andare nell'aria transcript è avviare la trascrizione.
Invece se potessi farlo direttamente da e automatizzare, magari l'azione nel momento in cui è metto un mp nella mia cartella podcast e con un certo c'è un certo formato e il gelo fa qualche anno a questo servizio ho avuto chiama chiamano questo servizio.
Questo potrebbe essere molto interessante.
Ecco, questa è la direzione che voglio prendere a corredo di quello che il podcast quindi boh esplode, no, probabilmente anche un po' il mondo.
So che non conosco perché io sono sviluppatore esperto l'indicizzazione però lo faremo insieme.
Sarà un'esperienza che condivide un confine.
Sono ormai passati quattro minuti di anticipazione, dobbiamo andare ai contenuti.
Oggi parliamo di paterne, di programmazione e parliamo dei pater o rom.
Intanto una premessa va fatta penso li conosciate, ma comunque voglio farla per in qualche modo introdurre il concetto di paternità.
In informatica quello che noi andiamo a fare con la programmazione è quella di creare delle soluzioni.
Ha dei problemi.
I problemi alle volte possono essere ricorrenti, per cui ricorrenti o assimilabili, per cui utilizzare una soluzione che è fitta.
Con quel problema la diciamo, ci aiuta.
Per cui è possibile utilizzare una soluzione che abbiamo individuato precedentemente per un problema simile al nostro nuovo problema, per cui il potere è una soluzione comune a un problema ricorrente, possibilmente anche ottimizzata.
Diciamo che la best practices delle soluzioni a un problema ricorrente.
Bene, qual è allora il problema ricorrente che andremo ad analizzare oggi? Beh, parliamo della persistenza.
Tutte le nostre buona parte delle nostre applicazioni devono in qualche modo avere una memoria, quindi devono salvare i dati.
Il salvataggio di questi dati solitamente lo si fa all'interno di un database o di basi di dati.
Queste permettono che qualunque cosa succeda al al nostro sistema in qualche modo e i nostri dati, qualora si spengano i servano, i nostri dati sono sempre raggiungibili.
E diciamo che la persistenza può essere fatta con tecnologie differenti, a partire dal classico database.
Ma se quelle opposte grande nell'ecosistema lampo ha già dei sistemi più complessi come Mongo, DBA, E', Cassandra, che sono dei noi, se quelle o a un grave di bio o un reddito.
Insomma, la persistenza può utilizzare tecnologie diverse, ma è la torniamo per un secondo alla persistenza coi database relazionali.
Quindi parliamo di posare parliamo di maestri, quelle in qualche modo l'azione di persistere all'interno del database fa parte dell'insieme delle azioni legate alla piattaforma che stanno nel nostro codice.
Quindi tutte le funzioni che vanno interagire sulla piattaforma cosa vanno a fare queste funzioni per queste funzioni non fanno altro che prendere gli oggetti del nostro software e trasformarli il record, che sono invece un concetto molto più vicino alla al database stesso e poi a sua volta vanno a prendere i record figli di query e li vanno a trasformare in oggetto ti del nostro sistema mi verrebbe da dire in oggetti del dominio qualora appunto programma massimo, utilizzando appunto l'approccio di dd domani in però comunque in oggetti che sono legati al nostro software quando era all'universita' un po' di anni fa, iniziano a essere un bel po.
Questo è incappato in codice dove in mezzo al codice c' erano le query.
Se quelle quindi royce e quelle in mezzo al php, per esempio, visto che era quello il linguaggio che io trattavo bene mettere il linguaggio e se quelle in mezzo al php capite bene che non è la scelta migliore e quindi si aveva la necessità e si ha la necessità di utilizzare degli oggetti per chiamati, anche rom che si occupa appunto, come dicevo prima, di trasformare gli oggetti il record dei record in oggetti nel nostro software.
Il compito infatti dello è quello di gestire lato nostro applicativo tutti i processi per la persistenza nella memoria fisica.
Quali sono i vantaggi che abbiamo nell'utilizzo di una RM? Intanto non mettiamo le sequenze in mezzo al nostro codice.
Mischiare i linguaggi non è mai una cosa buona, perché comunque serve un certo sforzo mentale per passare da un linguaggio all'altro mentre stiamo leggendo il nostro codice B, perché comunque potrebbero e gliele quelli se quelle potrebbero dover essere gestite da un'altra persona e quindi tutto insieme diventa caotico.
Altro vantaggio che ci permettono la rm, quello della validazione.
Possiamo infatti inserire un livello di validazione, una lista di costruire in nel nostro codice senza demandare la validazione e direttamente al database.
Questo è un vantaggio perché in realtà possiamo gestire meglio gli errori di validazione.
Invece quando una quelli fallisce, sapete bene che la risposta è sempre legata alla stessa non all'azione che si sta andando a fare.
Un altro vantaggio importante è quello di ridurre il codice.
Infatti le se quelle di per sé come linguaggio è molto verboso.
Quindi per fare una qui dobbiamo scrivere parecchio.
Ecco gli o r m mettono a disposizione dei terribili leader che, diciamo ci aiuta no al nella scrittura di una query è un'altra cosa importante, appunto quella che vi dicevo prima dell' ordine, infatti possiamo facilmente dividere in questo modo le quelle segue il dal nostro dominio.
Naturalmente, come tutte le cose, come vi dico sempre spesso le soluzioni più belle hanno comunque dei limiti dei difetti.
Beh, uno di questi limiti è appunto il fatto che la RM produce più quelli per eseguire appunto un certo blocco di codice potrebbe generare piu' quelli di quelle che in realtà potrebbero essere necessarie nella scrittura del codice.
Se quelle però è vero anche che dei dei tool moderni come doctrine introducono dei concetti, come per esempio fuori e poi andremo a vedere che in qualche modo ottimizza e rende più più performante il il il nostro codice, eseguendo in una sola transazione appunto le nostre piu' query.
Certo è e rimane comunque inefficiente.
Perché perché l'ottimizzazione il tuning che possiamo fare quando agiamo direttamente nelle query.
Non è lo stesso che possiamo fare usando.
Lo verremo anche questo è parzialmente vero, nel senso che e' doctrine mette a disposizione il linguaggio di quelle che non è altro che una sorta di astrazione di livello superiore del linguaggio.
Se quelle e abbiamo meno controllo, questo è ovvio, è quindi tutto ci sembra più magico e soprattutto il problema vero è un altro.
Il problema è che quando noi scriviamo codice e se quelle nella nostra applicazione per forza siamo spinti a pensare un minimo all'ottimizzazione, quindi siamo spinti scrivendo il codice se quelle a dire sì, va bene, ma forse questa gioia faccio in quest'altro modo non la faccia in quest'altro modo, ma quando noi utilizziamo questi tool siamo in qualche modo invogliati a concentrarci di piu' sul dominio applicativo, quindi su quelle che sono le vere funzioni pratiche che il nostro software va ad eseguire, per cui in qualche modo scriviamo del codice senza avere l'ottimizzazione in testa e quindi diventa meno performante.
Fatta questa introduzione, però, è capito cosa sono gli oggetti.
Vorrei introdurvi le due implementazioni più importanti più famose della rm la prima, la seconda invece è il data mart per il primo pattern che andremo a vedere, il pattern active records che tradotto letteralmente vuol dire record attivi, quindi record con una serie di azioni sono degli oggetti.
Sono degli oggetti le cui proprietà in un modo o nell'altro vanno a mappare le colonne eh, si occupano della appunto trasporto tra dei dati dalla nostra applicazione al database quasi possiamo quasi immaginarlo come un ponte invisibile.
Cosa possono fare queste? Beh, gli active records hanno funzionalità diverse, intanto tengono i dati, quindi un oggetto detiene, archivia in qualche modo prende in uso i dati di un record o specifico.
Oltre a questo però si occupano delle azioni di persistenza, quindi implementano il metodo saw eh si occupano anche di andare a ottenere di fare rete live dei il di di record dalla tabella di un insieme di record alla tavola, quindi sono anche delle collection delle collezioni di dati.
La cosa e' un po' strana in realtà e suono un pochino male pensare che in realtà un oggetto possa essere elemento di una collection, ma ti permette anche di avere indietro una collection stessa.
Però diciamo questa è la funzionalità active records che per sua natura è molto semplice da realizzare, ma ha dei limiti all'interno no a vedere i vantaggi.
Stesso dubbio i record sono accoppiati con gli oggetti, quindi la nostra la nostra struttura del database la ritroviamo pedissequamente all'interno dell' oggetto che andremo a maneggiare nel nostro codice.
Questo è un vantaggio perché in realtà in un solo colpo io conosco due sistemi e non mi vado a incasinare.
E quindi quando leggo il database, capisco direttamente alla struttura dell'applicazione senza dover stare là a leggere dei livelli intermedi che mi vanno a trasformare gli oggetti di dominio in schema di database.
Un altro vantaggio sempre legato a questo, a questa relazione forte con lo schema del database e il fatto che in un solo colpo, con degli algoritmi non troppo complessi, io posso generare degli oggetti dallo schema stesso.
E diciamo che funzionale, quando si ha bisogno di un approccio facile e veloce, perché in realtà interagire con oggetti che implementano il Pater Active Records ci permette, per esempio di non inizi inizializzare tutte le proprietà nel nostro oggetto per fare il collegamento con le colonne.
Insomma, cittalia tutta una serie di livelli di complessità che in Un'applicazione Enterprise sono molto utili, ma nello sviluppo di una neanche troppo complesso ben potrebbero essere over killer Nella realtà i vantaggi record sono anche i suoi limiti.
Uno dei suoi limiti è appunto questo accoppiamento db oggetto software.
Infatti è difficile utilizzare oggetti senza andare interagire col D B.
Faccio un esempio di ampliamento la mia logica di dominio nella mia applicazione Prendiamolo.
Carrello che questo oggetto carrello, essendo implementato con il pattern active record va interagire col database.
Ma se io volessi utilizzare il crea ordine, per esempio, può interagire con l' ordine senza dover necessariamente interagire col database.
Beh, potrei avere dei problemi tra l'altro.
Un altro limite importante è quello di testarli questi oggetti.
Perché? Perché in realtà, avendo un legame così stretto con l'architettura con livello di didi infrastruttura, fare un test unitario diventa più complesso.
Non dico che sia impossibile perche' comunque possibile testarli.
Però, per esempio, se tu vai a testare un modello e' eloquente, diciamo che puoi testare i metodi che alcuni metodi non tutto, anche perché magicamente appaiono per esempio delle proprietà che sono quelle che si fanno generale automaticamente.
Nel momento in cui ho collego il modello di eloquente che è lo RM di Rafael e al database in un altro limite.
Lo troviamo quando andiamo a sviluppare la nostra su dei database che esistono già.
Quando sviluppiamo la nostra esige che esistono già, impacchettiamo con un limite che è quello che il database potrebbero essere scritto male, diciamo i nomi delle colonne potrebbero non essere i migliori, oppure la struttura stessa dei database delle tabelle non rispecchia e pedissequamente quella che la struttura concettuale di dominio per per cui usando, diciamo il pattern active Records, mi trovo davanti al problema che gli oggetti che poi mi porterò ha preso in tutto lo sviluppo della logica di business della nostra applicazione.
Avranno lo stesso schema di una tabella del database che non ho sviluppato io, che magari non mi piacciono, non fa quello che deve fare.
E quindi insomma, potrebbe essere un limite, anzi, lo è sicuramente quando noi andiamo a fare delle web complesse.
E poi un altro limite del Pater Active Records è senza dubbio il fatto che all'aumentare della complessità del numero dei record le performance vanno a diminuire.
Questo perché in realtà nemmeno io parlo di eloquente che è quello che conosco meglio.
Non è previsto il concetto così come invece implementa un altro Patrick è quello del data.
Ma perche' andremo a vedere dopo che è quello della riunito fuori c'è anche questo concetto lo andremo a vedere con più calma.
Per cui diciamo che e'.
Il vantaggio di un approccio record è quello di avere degli oggetti facili, facilmente gestibili, degli oggetti che rispecchiano la stessa struttura del database.
Quindi ho leggendo il database presto capito come è strutturata la la mia applicazione ne diciamo un approccio abbastanza facile.
Di contro ci sono tutte, appunto i limiti che abbiamo detto prima.
Il secondo pattern che andiamo a vedere si chiama il data, ma per per capirci, è quello utilizzato da Doctrine RM di Symphony.
Parlo di PHP perché il mondo che più mi stava vicino e che ha il compito di creare un per un livello intermedio tra il dominio della nostra applicazione, il DB, infatti, dominio idb risultano essere indipendenti.
Questa indipendenza ci permette, per esempio, di sviluppare un approccio dove io mi concentro semplicemente sull'entità del mio dominio e poi questa entità in qualche modo vanno a essere persistito all'interno del nostro sistema con l'approccio di data, ma per spesso le proprietà sono private, a differenza appunto record.
La scrittura e la lettura di queste proprietà avviene attraverso dei metodi e accessori che appunto espongono queste proprietà.
Però the per accedere a queste proprieta' devi passare attraverso di loro.
Questo ci permette, per esempio di validare delle costringe al posto di andare a scrivere direttamente e questi sistemi collegano in qualche modo la nostra logica di dominio col database e lo fanno attraverso modi diversi.
Lo fanno attraverso, per esempio dei file di configurazione XML o in y ml di Amal o lo fanno attraverso i commenti, perché no doctrine, per esempio, quando si vuole sviluppare in modo molto rapido, basta inserire delle annotazioni chiamala notation sopra le proprietà per decidere cosa mappare e come farlo.
Questo livello ulteriore e fa da bridge e fa da ponte tra il dominio.
Quindi tutto ciò che riguarda le costrette in tutte le azioni che vada a fare sulle proprietà che sono strettamente legate alla vostra logica di dominio, alla persistenza, alla mera persistenza stessa.
Questo ci permette in realtà una cosa molto semplice che una cosa non contemplata che il concetto di singola responsabilità single responsability.
E infatti la nostra in TT ha un'unica responsabilità quella di gestire le costruendo le regole di business che la riguardano.
Tutto il resto, la persistenza, la ricerca è demandato ad altri elementi del sistema non se ne occupa lei.
Per cui avendo una distinzione così netta, così semplice quando un problema solo che l'oggetto hand it contiene quel quel quella porzione di azione, quella porzione di codice non dovro' impazzire andando a cercare o ma quella funzione quell'azione dove si trovava altro vantaggio vero e che le nostre identita' sono slegate dallo schema del database perché appunto le mappe usando delle configurazioni me li ha mai dei commenti per cui, essendo slegate, io posso agire con dei concetti che sono più vicini al mio dominio e meno vicini alla mia infrastruttura? Posso usare dei posso utilizzare il polimorfismo, quindi quando io vado a sviluppare questo codice diciamo che il livello database livello infrastruttura mi è comunque invisibile.
Naturalmente anche il data mappa paterna ha dei limiti, intanto è più barboso il perche' in un io devo definire proprietà e metodi accessori medio di lettere.
Per questo fa si' che non debba scrivere più codice occhio che è facile cadere scadere nel concetto del modello anemico che poi vedremo in un altro episodio per cui modello per cui diciamo che facciamo dell'entità dove abbiamo solo dei metodi, perché vanno impostare delle proprietà e non fanno nient'altro e tutto il resto delle costruzioni le buttiamo nel nostro controllo.
È facendo tenendo un modello a nemico e un controllo del grasso.
Ma questo poi sara' parte di un altro episodio per cui ci andremo a concentrare solo su quello un altro limite del data.
Ma per è senza dubbio il fatto che diventa spaventoso da configurare quando vai a configurare il modello e magari lo fa il suo ex.
Ma perche' vuoi tenere tutto perfettamente? Ne è una dimostrazione ed è più difficile esportare quella configurazione in modo automatico.
Adesso la domanda sorge spontanea qual è il miglior approccio che posso utilizzare? Beh, il primo ragionamento da fare Ehi, cosa devi fare? Cioè, non esiste un approccio migliore.
Non esiste decidere perché è il meglio assoluto.
E questo in informatica chiunque li propugna l'idea il concetto del meglio assoluto.
Vi sta dicendo una fesseria grande quanto il mondo, perché in realtà tutto dipende dal contesto e dall'infrastruttura che state andando a gestire.
Se avete un'applicazione semplice un prototipo che deve essere semplice e facile da sviluppare veloce soprattutto beh, lo andate a fare colpo per vivere.
Se invece vi trovate in un contesto tale per cui l'apache dovete fare magari di livello enterprise e complessa, magari eredita uno schema di persistenza, lo schema di database legacy e magari anche difficile, contorto, complesso, contattata belle relazioni contro le relazioni dati divisi in due o tre tabelle.
Beh, a quel punto il mio consiglio spassionato e' quello di utilizzare il data matteo è data, ma per che vi mette a disposizione tutti gli strumenti per semplificare quel contesto difficile.
Questo approccio, se ci pensate un attimo, ce lo riportiamo anche sui framework.
Vi ho fermato un attimo per ragionare su questa cosa.
Prendiamo due dei più famosi php uno e la pelle e' una sinfonia premesso che condividono una larga parte del codice, visto che la Ravel si basa e attinge a piene mani da quelli che sono i symphony componenti mattoni che vanno a creare anche symphony, in realtà l'approccio completamente diverso.
La roba è pensato per applicazioni semplici e rapide da sviluppare un approccio no development dove meno codice scrivi e più rapidamente lo fai prima riesce a ottenere il prototipo.
Sinfonia invece utilizza un approccio un pochino più strutturato.
Infatti ce ne andiamo a vedere, ma le api enterprise che è meglio conosciamo, sono che molte di queste sono fatte con Symphony.
Questo perché in realtà ti mette a disposizione tutta una serie di strumenti che all'inizio presuppongono una fronte di complessità, una curva ripida in termini di export di sforzo, ma poi ti permettono di gestire situazioni complesse e ci sono meno magie, meno metodi che cose che accadono e non lo riesce a vedere il codice.
E questo si riporta appunto anche nei persistenza.
Se noi andiamo a vedere quello che è il partner che viene usato dal al quindi eloquente, vediamo che un active records se noi andiamo a vedere invece il pattern utilizzato da Symphony.
Vediamo chi utilizza doctrine due che è un documento, ma per quindi in realtà vedete che non esiste uno strumento migliore, ma esistono approcci diversi.
Quindi da questo punto di vista io ribadisco quello che vi ho detto prima.
Scegliete la chiave inglese che volete utilizzare a seconda del bullone che avete davanti.
Non anche questa puntata è appena terminata.
È registrata anche questa in macchina perche' non sono ancora trattato a lione, ma sto usando un nuovo ferite, spero sia migliore.
Ecco, spero intanto è più pratico e questo è un vantaggio.
E poi spero che LaHood che sto producendo possa essere in qualche modo fruibile.
Vi ricordo che questa settimana spero di iniziare al più tardi la prossima.
Spero di iniziare con le dirette tucci vedrò se fare qualcosa, collegarlo anche con i tubi.
Però nel frattempo vi chiedo una cosa se la mia puntata vi è piaciuta e in qualche modo volete entrare in contatto con me, potete farlo scrivendo mi ha heat breve, sto valutando l'idea in realtà di passarvi il contatto telegramma fare un gruppo delega pero' so è solo un'idea.
Non ho ancora deciso cosa fare, per cui potete entrare in contatto con me su twitter, dirmi se se qualcosa vi è piaciuto oppure dirmi se ho detto qualche fesseria.
In quel caso sono pronto a fare follie l'acqua nella prossima puntata e nulla è come dicevo, se vi fa piacere.
Ecco aprite la vostra preferita di podcast che si augura al podcast che si ha un podcast casta ma poche cast e ce ne sono settantamila.
Cercate chi sbarra gli scrive alla sardegna e soprattutto vi condividero' la foto sono davanti alla spiaggia perché sto registrando in macchina.
E' tutto un saluto e ci vediamo in streaming questa settimana con la prossima puntata la settimana prossima.
Ciao Bar, il circolo dei full Stack E' Bello.
Per una volta a settimana ci troviamo davanti a due birre e compra il ceppo.
Parliamo linguaggi e tecniche di sviluppo web, di metodologie e di strumenti immancabili nella cassetta degli attrezzi dei fusti.
Ho bisogno di una mano. Aiutami a rendere più conosciuto il nostro podcast. Parlane con gli amici o con i colleghi e iscriviti usando Apple Podast o Google Podcast. Questa tua azione ci aiuterà a salire nella classifica dei podcast di tecnologia ed essere utili anche a qualcun’altro. Se non ti va, amici come prima😄