[ORM] Cos'è e quali sono i vantaggi?

[x3d0]

Ho sentito parlare di ORM come Doctrine ma non ho men capito cosa siano.

Potreste farmi degli esempi concreti?
Potrebbe essermi utile nella realizzazione di un pannello di amministrazione?

[khelidan1980]

Ho sentito parlare di ORM come Doctrine ma non ho men capito cosa siano.

Potreste farmi degli esempi concreti?
Potrebbe essermi utile nella realizzazione di un pannello di amministrazione?

http://it.wikipedia.org/wiki/Object-relational_mapping

[shinya]

Sui vantaggi... è una faccenda controversa.
Se vuoi leggere un pò di opinioni eterogenee, se ne è discusso recentemente su reddit:
http://www.reddit.com/r/programming/comments/9t7aa/a_farewell_to_orms/

[zulutown]

Ho sentito parlare di ORM come Doctrine ma non ho men capito cosa siano.

Potreste farmi degli esempi concreti?
Potrebbe essermi utile nella realizzazione di un pannello di amministrazione?

Su Java EE c'è JPA che è a mio parere fantastico (certo, con ampi margini di miglioramento... ma rispetto a non averlo è un altro mondo)

in poche parole se tu volessi estrarre dal DB un utente e i suoi messaggi, dovresti fare una join tra due tabelle.
Se in JPA volessi far la stessa cosa fai

Utente utente = getEntityManager.find(Utente.class, "m.rossi");

System.out.println(utente.getNome + utente.getCognome());
for (Messaggio messaggio : utente.getMessaggi()) {
System.out.println(messaggio.getTitolo() + messaggio.getTesto();
}



In pratica ti fai dare l'oggetto Utente (che è una @Entity gestita via ORM) e poi puoi accedere ai dati usando semplicemente i getter dei bean.

Ovviamente condizione necessaria è sapere usare JPA!
Se non la sai usare o la usi male, ci perdi più tempo, ma se lo sai usare, tutto si fa in un decimo del tempo.

[shinya]

In pratica ti fai dare l'oggetto Utente (che è una @Entity gestita via ORM) e poi puoi accedere ai dati usando semplicemente i getter dei bean.

Ovviamente condizione necessaria è sapere usare JPA!
Se non la sai usare o la usi male, ci perdi più tempo, ma se lo sai usare, tutto si fa in un decimo del tempo.
Con gli esempi stile "select * from table" sono capaci tutti. E' facile dire "che figata 'sti ORM!!" quando non lavori in un ambiente ostile.
Fammi un esempio più complesso e vediamo se ci metti ancora un decimo del tempo... e con complesso intendo anche solo qualcosa come: l'oggetto Utente non si può costruire con una select da una tabella 'Utenti', ma le informazioni sono sparse su più tabelle, magari su database diversi... peccato che tu su uno dei database non possa fare select dalle tabelle perchè "le policy aziendali sono queste" ma si debba reperire i dati da una qualche procedura PL/SQL. Ah dimenticavo, deve funzionare su Websphere, non su Glassfish (troppo facile!), e con i driver JDBC di Oracle (buggati). Ah... non dimenticare della foto dell'utente in quella colonna di tipo BLOB...

[RaouL_BennetH]

Con gli esempi stile "select * from table" sono capaci tutti. E' facile dire "che figata 'sti ORM!!" quando non lavori in un ambiente ostile.
Fammi un esempio più complesso e vediamo se ci metti ancora un decimo del tempo... e con complesso intendo anche solo qualcosa come: l'oggetto Utente non si può costruire con una select da una tabella 'Utenti', ma le informazioni sono sparse su più tabelle, magari su database diversi... peccato che tu su uno dei database non possa fare select dalle tabelle perchè "le policy aziendali sono queste" ma si debba reperire i dati da una qualche procedura PL/SQL. Ah dimenticavo, deve funzionare su Websphere, non su Glassfish (troppo facile!), e con i driver JDBC di Oracle (buggati). Ah... non dimenticare della foto dell'utente in quella colonna di tipo BLOB...

Non arrivo ai livelli di complessità da te descritti :p , ma almeno per la selezione da più tabelle ci si arriva davvero in attimi. L'entità Utente (per continuare con l'esempio) è appunto un'entità e non rappresenta UNA tabella del db.

Una volta definità l'entità come classe, e mappata (il come dipende a seconda dell'orm) se anche le informazioni di un utente sono sparse per nmila tabelle, non ha alcuna rilevanza.

Un piccolissimo esempio di map su diverse tabelle(utilizzando NHibernate):




<class name="Utente" table="anagraficaUtente">
<id name="ID" column="utenteId" type="Int32">
<generator class="identity"></generator>
</id>
<property name="Cognome" blablala></property>
<join table="telefoniUtente">
<key column="utenteId"></key>
<property name="asdasdasdasd" blalblabla></property>
</join>
<join table="quanteSigaretteFumaUtente">
<key column="utenteId"></key>
<property name="blbalbalbalbalblab"etc....></property>
</join>
etcetera....


Questo solo per utilizzare delle semplici join (in presenza magari di foreign keys fra le tabelle). Si possono ovviamente applicare le varie relazioni uno a uno/molti etc..

La cosa pratica è che l'entità con cui avere a che fare da sorgente, è una sola.

[khelidan1980]

Con gli esempi stile "select * from table" sono capaci tutti. E' facile dire "che figata 'sti ORM!!" quando non lavori in un ambiente ostile.
Fammi un esempio più complesso e vediamo se ci metti ancora un decimo del tempo... e con complesso intendo anche solo qualcosa come: l'oggetto Utente non si può costruire con una select da una tabella 'Utenti', ma le informazioni sono sparse su più tabelle, magari su database diversi... peccato che tu su uno dei database non possa fare select dalle tabelle perchè "le policy aziendali sono queste" ma si debba reperire i dati da una qualche procedura PL/SQL. Ah dimenticavo, deve funzionare su Websphere, non su Glassfish (troppo facile!), e con i driver JDBC di Oracle (buggati). Ah... non dimenticare della foto dell'utente in quella colonna di tipo BLOB...

ma...lavoriamo nello stesso posto?? :D o meglio,o la vaga impressione che la maggioranza dei posto sia così....
quando hai a che fare con questa gente bisogna considerarsi furtunati che hanno pensato a fare il mirabolante passo da cobol a java.....

Comunque per utilizzare questi cosi bisogna applicare la "convention over configuration" anche perchè non so voi ma io non ho intenzione di programmare in xml!


P.s: websphere fa proprio schifo,questo è l'esempio principe di quanto conti un nome

[gokan]

Con gli esempi stile "select * from table" sono capaci tutti. E' facile dire "che figata 'sti ORM!!" quando non lavori in un ambiente ostile.
Fammi un esempio più complesso e vediamo se ci metti ancora un decimo del tempo... e con complesso intendo anche solo qualcosa come: l'oggetto Utente non si può costruire con una select da una tabella 'Utenti', ma le informazioni sono sparse su più tabelle, magari su database diversi... peccato che tu su uno dei database non possa fare select dalle tabelle perchè "le policy aziendali sono queste" ma si debba reperire i dati da una qualche procedura PL/SQL. Ah dimenticavo, deve funzionare su Websphere, non su Glassfish (troppo facile!), e con i driver JDBC di Oracle (buggati). Ah... non dimenticare della foto dell'utente in quella colonna di tipo BLOB...

ma...lavoriamo nello stesso posto??
Ho l'impressione di si :D
Dove lavoro io, in banca, all'inizio mi chiedevo pure io perchè non si utilizzasse qualcosa come JPA piuttosto che direttamente con JDBC (o meglio un wrapper di questo)...beh la risposta l'ho trovata strada facendo...considerate che tutto sta sopra database db2 che vengono usati solo per buttare dentro dati, mai visto utilizzo di chiavi primarie o esterne e chi ci lavorava fino ad adesso, non me ne vogliano i programmatori cobol di questo forum, hanno sempre fatto così..vi giuro che sono rimasti sorpresi quando noi javisti abbiamo proposto di usare delle colonne tipo id per mantenere un legame tra due tabelle..azzo manco le join vogliono fare :muro:

Tutto questo per dire che non vedrei grossi vantaggi nell'usare un ORM in un contesto simile.

[cdimauro]

Arrivato in azienda a fine 2004, quando ho fatto vedere che con le foreign key i record delle tabelle slave venivano automaticamente cancellati, hanno fatto una faccia così :eek: e mi hanno detto: "ma davvero non serve scrivere codice PHP per cancellare poi tutti i record dell'altra tabella"?

Transazioni, trigger e stored procedure? Fantascienza. Sono stato il primo a usarli, e ancora oggi credo di essere l'unico ad aver fatto uso di questi ultimi due. E siamo a fine 2009...

Quanto agli ORM, concettualmente mi piacciono, ma a conti fatti e nella vita di tutti i giorni ho sviluppato una sorta di wrapper che genera automaticamente codice SQL per le SELECT, INSERT, UPDATE e DELETE (simile a LINQ, per intenderci): di gran lunga più comodo e semplice da usare.

A me servono strumenti agili per lavorare.

[zulutown]

Con gli esempi stile "select * from table" sono capaci tutti. E' facile dire "che figata 'sti ORM!!" quando non lavori in un ambiente ostile.
Fammi un esempio più complesso e vediamo se ci metti ancora un decimo del tempo... e con complesso intendo anche solo qualcosa come: l'oggetto Utente non si può costruire con una select da una tabella 'Utenti', ma le informazioni sono sparse su più tabelle, magari su database diversi... peccato che tu su uno dei database non possa fare select dalle tabelle perchè "le policy aziendali sono queste" ma si debba reperire i dati da una qualche procedura PL/SQL. Ah dimenticavo, deve funzionare su Websphere, non su Glassfish (troppo facile!), e con i driver JDBC di Oracle (buggati). Ah... non dimenticare della foto dell'utente in quella colonna di tipo BLOB...

ma che ragionamento è? se ovviamente parti da un DB già esistente fatto con il culo... è logico che non sia banale in ogni caso integrare JPA o altro.
Conosco ho colleghi che in ambiti enterprise tramite wrapping vari riesce a usare le comodità di JPA anche su database legacy.

Comunque se hai un database strutturato decentemente, piuttosto che fare 10 join con SQL, tramite JPA e le relazioni tra oggetti tutto è mille volte più veloce.

[tomminno]

Comunque se hai un database strutturato decentemente, piuttosto che fare 10 join con SQL, tramite JPA e le relazioni tra oggetti tutto è mille volte più veloce.

Scusa ma se parliamo di comodità può essere che gli ORM battano tutto il resto, ma se parliamo di velocità assolutamente no.
Una query SQL è molto più veloce di qualunque astrazione software tu ci possa mettere sopra, semplicemente perchè lo strumento automatico non genererà mai una query ottimizzata come potrebbe fare una mente umana.

Più o meno lo stesso discorso sulla velocità di esecuzione/velocità di sviluppo tra Assembly-C-Linguaggi Managed

[zulutown]

Scusa ma se parliamo di comodità può essere che gli ORM battano tutto il resto, ma se parliamo di velocità assolutamente no.
Una query SQL è molto più veloce di qualunque astrazione software tu ci possa mettere sopra, semplicemente perchè lo strumento automatico non genererà mai una query ottimizzata come potrebbe fare una mente umana.

Più o meno lo stesso discorso sulla velocità di esecuzione/velocità di sviluppo tra Assembly-C-Linguaggi Managed
ovviamente parlo di velocità in termini di sviluppo.
costa molto meno comprare hardware più potente che pagare il doppio di ore gli sviluppatori
PS: e anche sul discorso velocità del prodotto non è sempre detto, dipende da come sanno scrivere bene SQL i programmatori.

[banryu79]

Più o meno lo stesso discorso sulla velocità di esecuzione/velocità di sviluppo tra Assembly-C-Linguaggi Managed
Quoto solo qesto pezzo: il tuo ragionamento magari ha senso per ORM versus SQL scritto a manina, viceversa è tutto fuori che scontato il fatto che a runtime il compilato di codici C o C++ esegua più velocemente del just-in-time-compilato dei linguaggi managed.

Cioè il paragone tra "query ORM versus query SQL scritte a mano" e "codice ottimizzato a mano assembly/C/C++ versus linguaggi managed" è sbagliato.

E il motivo è che la complessità delle ottimizzazioni per sua natura non ha a che fare solo con aspetti statici del codice, valutabili quindi in maniera esaustiva da una mente umana, ma comprende aspetti dinamici, conoscibili solo a runtime, e questi aspetti possono essere presi in considerazione solo da appositi strumenti che esaminano le condizioni di runtime ed eseguono al volo eventuali ottimizzazioni.

[zulutown]

Comunque per utilizzare questi cosi bisogna applicare la "convention over configuration" anche perchè non so voi ma io non ho intenzione di programmare in xml!


con JPA non si usa XML si usano le annotation.

[khelidan1980]

con JPA non si usa XML si usano le annotation.

bello sinceramente non lo mai usato JPA,io ovviamente mi riferivo a hibernate & company e più in generale al 99% dei framework java,spring struts ecc...per i mei gusti sono troppo xml-centrici...

[tomminno]

Quoto solo qesto pezzo: il tuo ragionamento magari ha senso per ORM versus SQL scritto a manina, viceversa è tutto fuori che scontato il fatto che a runtime il compilato di codici C o C++ esegua più velocemente del just-in-time-compilato dei linguaggi managed.


Che dire per la mia esperienza il codice se portato da C# (o un linguaggio gestito) a C++ è sempre risultato ben più veloce, o per lo meno a parità di funzionalità il tempo di elaborazione non mi ha mai smentito.
L'ennesima riprova l'ho avuta di recente quando tra 2 applicativi uno Java e uno C++ (o meglio in C con le classi, dato che del C++ usava solo la OO) sulla stessa macchina per distribuire lo stesso filmato il primo impiegava la cpu al 90% l'altro neanche si faceva sentire con un'occupazione di ram ridicola (11Mb). Con il secondo software sono arrivato a tirare il collo all'applicativo (e alla lan gigabit) ben prima di saturare minimamente la macchina, con il secondo la macchina era già che morta con un numero irrisorio di client.

E in ogni caso c'è sempre il costo di questi ottimizzatori a runtime (che non ho mai capito fino a che punto e come riescano ad ottimizzare codice reale).

In ogni caso è innegabile che a livello di velocità se devo lavorare con istruzioni SIMD e scrivo una routine assembly il codice nel complesso migliora in prestazioni che non a caso è quello che viene fatto in tutte le librerie codec AV per esempio.


Cioè il paragone tra "query ORM versus query SQL scritte a mano" e "codice ottimizzato a mano assembly/C/C++ versus linguaggi managed" è sbagliato.


Chiaramente il rapporto Orm-SQL/Assembly-C-Resto del mondo è analogo solo parzialmente perchè Sql è un'interfaccia verso un sistema esterno al programma, un orm fornisce tante funzionalità in più che sono estranee a sql e riguardano solo lo sviluppo. I linguaggi invece sono praticamente paritetici dal punto di vista delle funzionalità.


E il motivo è che la complessità delle ottimizzazioni per sua natura non ha a che fare solo con aspetti statici del codice, valutabili quindi in maniera esaustiva da una mente umana, ma comprende aspetti dinamici, conoscibili solo a runtime, e questi aspetti possono essere presi in considerazione solo da appositi strumenti che esaminano le condizioni di runtime ed eseguono al volo eventuali ottimizzazioni.

Questo è vero per il codice e meno per l'sql, che dopotutto viene ottimizzato dal server, dopotutto il compito del programma dovrebbe essere quello di scrivere query che sono massimamente ottimizzabili dal server.

Comunque anche dove lavoro io per il momento usiamo un tool che mappa le tabelle in classi e crea metodi per l'interazione di queste con il database, ma abbiamo ancora i DAL fatti a mano, anche perchè se c'è da fare una join al 99% si usano le viste (altra ottimizzazione, una vista è più efficiente di una query con join)

[banryu79]

@tomminno: ti ho risposto via pvt per evitare l'OT.Ciao.

[RaouL_BennetH]

bello sinceramente non lo mai usato JPA,io ovviamente mi riferivo a hibernate & company e più in generale al 99% dei framework java,spring struts ecc...per i mei gusti sono troppo xml-centrici...

Anche per .Net puoi evitare di usare gli xml utilizzando Fluent NHibernate (se utilizzi Nhibernate ovviamente... )

[tomminno]

Anche per .Net puoi evitare di usare gli xml utilizzando Fluent NHibernate (se utilizzi Nhibernate ovviamente... )

Oddio NHibernate è una piaga quanto a prestazioni.
Tanto vale usare l'Entity Framework della Microsoft: integrato in Visual Studio e molto più veloce.

[khelidan1980]

con JPA non si usa XML si usano le annotation.

perdona la mia sbadataggine ho connesso ora che jpa erano gli ejb 3.0 :D

E te credo che non si usano più gli xml,dopo aver sputato sangue letteralmente con le vecchie versioni di ejb!!!!