Quando utilizzare Hibernate / JPA / Toplink?

StackOverflow https://stackoverflow.com/questions/122571

Domanda

In questo momento sto realizzando un sito estremamente semplice di circa 5 pagine. La domanda è se sia eccessivo e valga la pena di integrare una sorta di soluzione di mappatura del database o se sarebbe meglio usare semplicemente il vecchio JNDI. Avrò forse una dozzina di cose che devo leggere / scrivere dal database. Immagino di avere una conoscenza di base di queste tecnologie, ma sarebbe comunque necessario fare molto riferimento alla documentazione. Qualcun altro ha affrontato la decisione prima?

EDIT: mi dispiace, avrei dovuto specificare JNDI per cercare la connessione DB e JDBC per eseguire le operazioni.

È stato utile?

Soluzione

Risposta breve: dipende dalla complessità che si desidera supportare.

Risposta lunga:

Prima di tutto, ORM (mappatura relazionale degli oggetti - mappatura del database come la chiami tu -) e JNDI (Java Naming e Directory Interfaces) sono due cose diverse.

Il primo, come già sapete, viene utilizzato per mappare le tabelle del database su classi e oggetti. Il secondo è fornire un meccanismo di ricerca delle risorse, che possono essere DataSource, Ejb, Queues o altri.

Forse il tuo "JDBC" "

medio

Ora come per la tua domanda: se è così semplice potrebbe non essere necessario implementare un ORM. Le tabelle dei numeri sarebbero al massimo intorno ai 5-10, e immagino che le operazioni siano davvero semplici.

Probabilmente sarebbe sufficiente usare JDBC semplice.

Se si utilizza il modello DAO, è possibile modificarlo in un secondo momento per supportare la strategia ORM, se necessario.

In questo modo: Supponi di avere la tabella Employee

Crea Employee.java con tutti i campi del DB manualmente (non dovrebbe richiedere troppo tempo) e EmployeeDaO.java con metodi come: 

+findById( id ): Employee
+insert( Employee ) 
+update( Employee )
+delete( Employee ) 
+findAll():List<Employee>

E l'implementazione è abbastanza semplice: 

select * from employee where id = ?
insert into employee ( bla, bla, bla ) values ( ? , ? , ? )
update etc. etc

Quando (e If) l'applicazione diventa troppo complessa, è possibile modificare l'implementazione DAO. Ad esempio in " seleziona " metodo si modifica il codice per utilizzare l'oggetto ORM che esegue l'operazione. 

public Employee selectById( int id ) {
      // Commenting out the previous implementation...
      // String query = select * from employee where id = ? 
      // execute( query )  

      // Using the ORM solution

       Session session = getSession();
       Employee e = ( Employee ) session.get( Employee.clas, id );
       return e;
}

Questo è solo un esempio, nella vita reale potresti lasciare che la fabbrica abstact crei il DAO ORM, ma è offtopico. Il punto è che potresti iniziare in modo semplice e utilizzando i modelli di progettazione puoi modificare l'implementazione in un secondo momento, se necessario.

Ovviamente se vuoi imparare la tecnologia puoi iniziare subito con anche 1 tavolo.

La scelta dell'uno o dell'altro (soluzione ORM) dipende fondamentalmente dalla tecnologia che stai utilizzando. Ad esempio per JBoss o altri prodotti open source Hibernate è fantastico. È opensource, ci sono molte risorse da cui imparare. Ma se stai usando qualcosa che ha già Toplink (come l'oracle application server) o se la base è già costruita su Toplink dovresti rimanere con quel framework.

A proposito, da quando Oracle ha acquistato BEA, hanno detto che stanno sostituendo Kodo (weblogic peresistence framework) con toplink nell'ormai chiamato " Oracle Weblogic Application Server " ;.

Vi lascio alcune risorse in cui è possibile ottenere maggiori informazioni al riguardo:

In questo "Patterns of Enterprise Application Architecture" libro, Martin Fowler, spiega dove usare l'uno o l'altro, ecco il catalogo. Dai uno sguardo ai modelli architettonici dell'origine dati rispetto ai modelli comportamentali relazionali agli oggetti:

Catalogo PEAA

DAO (Data Access Object) fa parte del catalogo dei pattern J2EE di base:

Il modello DAO

Questo è un tutorial iniziale per Hibernate:

Hibernate

La pagina ufficiale di Toplink:

Toplink

Finalmente io "penso" la buona idea di JPA è che potresti cambiare provider di recente.

Inizia semplice e poi evolvi.

Spero che questo aiuti.

Altri suggerimenti

Sembra che sarebbe eccessivo per un'applicazione molto semplice, soprattutto se non hai intenzione di espanderlo mai. Tuttavia, sembra anche che valga la pena usare quelli con questa semplice applicazione in modo da avere una migliore comprensione di come funzionano per la prossima volta che hai qualcosa che potrebbe usarli.

Intendi semplicemente il vecchio JDBC? Un piccolo progetto potrebbe essere una buona opportunità per raccogliere uno dei framework ORM, specialmente se hai tempo.

Senza ulteriori informazioni, tuttavia, è difficile fornire una raccomandazione in un modo o nell'altro.

La mia regola empirica è se è di sola lettura, sono disposto a farlo in JDBC, anche se preferisco usare un progetto Hibernate vuoto con SQLQuery per sfruttare la mappatura dei tipi di Hibernate. Una volta che devo scrivere, vado con Hibernate perché è molto più facile impostare alcuni attributi e quindi chiamare save piuttosto che impostare ciascuna colonna singolarmente. E quando devi iniziare l'ottimizzazione per evitare aggiornamenti su oggetti invariati, stai molto meglio con un OR / M e il suo controllo sporco. Gestire le relazioni con le chiavi esterne è un altro segno che è necessario mapparlo una volta e quindi utilizzare i getter. La stessa logica si applicherebbe a Toplink, anche se a meno che non abbiano aggiunto qualcosa come HQL nei 3 anni da quando l'ho usato, Hibernate sarebbe molto meglio per questo tipo di transizione da puro SQL. Tieni presente che non è necessario mappare ogni oggetto / tabella, solo quelli in cui esiste un chiaro vantaggio. Nella mia esperienza, la maggior parte dei progetti che non utilizzano un OR / M esistente finiscono per costruirne uno nuovo, il che è una cattiva idea.

Il miglior modo per imparare l'ORM è su un piccolo progetto. Inizia su questo progetto.

Una volta capito, userai ORM per tutto.

Non c'è niente di troppo piccolo per ORM. Dopo i tuoi primi due progetti, scoprirai che non puoi lavorare in nessun altro modo. La mappatura ORM ha generalmente più senso di quasi qualsiasi altro modo di lavorare.

Guarda le varie guide toplink qui, hanno intro, esempi, scenari ecc.

http://docs.oracle.com/cd/ E14571_01 / web.1111 / b32441 / toc.htm

Autorizzato sotto: CC-BY-SA insieme a attribuzione
Non affiliato a StackOverflow
scroll top