[hibernate - java] perché dovrei usare un pattern DAO?

[MEMon]

Ciao a tutti, qualunque cosa cerco riguardo a hibernate salta fuori sto pattern DAO, che da quel che ho capito altro non è che che creare una classe che gestisca le CRUD di una "entity"(classe persistente che identifica una tabella nel db).
Ok, ci potrebbe anche stare come idea, ma:

Perché devo soffrire e crearmi per ogni entity una classe per gestirla?
Se poi devo cambiare qualcosa devo modificare la entity, e molto probabilmente anche la classe che ne gestisce le CRUD
Diventa tutto più lungo da fare e da mantenere, allora tanto vale che continuavo ad usare JDBC senza passare ad hibernate no?


Ora mi/vi domando, ma perché mi devo complicare la vita in questo modo usando questo pattern?

Le cose sono due, o non ho capito una mazza(molto molto probabile) o ci si è ingegnati per fare le cose più difficili.

Qualcuno mi potrebbe fare qualche esempio dove l'uso di un pattern DAO mi tornerebbe utile?

[khelidan1980]

spiegami, tu vorresti fare le operazioni CRUD direttamente chiamando le api di hibernate nelle tue classi di business??

[MEMon]

Che intendi per le classi di business?

Io comunque vorrei fare le operazioni che interessano una entity nella entity stessa ( come tra l'altro prevede l'OO), non vedo perché andare a creare un'ulteriore classe per fare ciò, che poi è da mantenere anche quella.

Ci sono motivi di perfomance? Si rompe qualcosa? Non so...

[khelidan1980]

il DAO serve per astrarre, dalle tue classi di logica chiami il dao senza sapere cosa hai sotto che fa la persistenza, cosi ti astrai dalla tecnologia e nel caso volessi cambiare implementazione dello strato di persistenza non ci sarebbero problemi

[MEMon]

il DAO serve per astrarre, dalle tue classi di logica chiami il dao senza sapere cosa hai sotto che fa la persistenza, cosi ti astrai dalla tecnologia e nel caso volessi cambiare implementazione dello strato di persistenza non ci sarebbero problemi

Intendi non ci sarebbero problemi tranne riscrivere il DAO?

[khelidan1980]

Intendi non ci sarebbero problemi tranne riscrivere il DAO?

esattamente, altrimenti dovresti toccare tutte le classi, non e niente di più che il concetto di API

[MEMon]

Intendiamoci, la mia intenzione era quella di fare circa la stessa cosa che si fa per creare un bel DAO, quindi interfaccia, classe astratta che la implementa e finalmente la classe DAO vera, con la sola differenza che la classe DAO finale che estende la classe astratta è la entity stessa!

In questo modo si andrebbero ad aggiungere metodi che in fin dei conti operano direttamente sulla entity nella entity stessa, e in più non ci si ritrova con tante classi, e per quanto mi riguarda non c'è il concetto classe che gestisce->classe gestita che lo trovo illogico.

Ovviamente se non si fa così ci deve essere un motivo...

[khelidan1980]

in questo modo sei comunque legato alla tecnologia sottostante, il pattern DAO serve appunto a dissaccoppiare l'implementazione della persistenza dalle tue classi di logica, con l'estensione l'accoppiamento rimane

il concetto classe gestita-classe che gestisce è un classico dei pattern, vedi Delegate :)

[MEMon]

in questo modo sei comunque legato alla tecnologia sottostante, il pattern DAO serve appunto a dissaccoppiare l'implementazione della persistenza dalle tue classi di logica, con l'estensione l'accoppiamento rimane

il concetto classe gestita-classe che gestisce è un classico dei pattern, vedi Delegate :)

Sei sempre legato alla tecnologia sottostante a dirla tutta, se si fanno i DAO poi si cambieranno quelli, se si mette tutto nelle entity invece si andranno a toccare le entity... il risultato non cambia in quei termini...

[tomminno]

In questo modo si andrebbero ad aggiungere metodi che in fin dei conti operano direttamente sulla entity nella entity stessa, e in più non ci si ritrova con tante classi, e per quanto mi riguarda non c'è il concetto classe che gestisce->classe gestita che lo trovo illogico.

Ovviamente se non si fa così ci deve essere un motivo...

Personalmente non vedo bene l'integrazione delle operazioni di CRUD sulle entity, in quanto significa legare la classe specificatamente all'utilizzo con database, quando in realtà l'entity è (per me) solo un contenitore di dati.
Oltretutto significa che l'entity deve conoscere il database da cui ha origine, ma non necessariamente l'oggetto avrà origine su database: se volessi serializzarla/deserializzarla su file? Se dovessi poi passarla ad un webservice? I metodi read e insert da db non andrebbero più bene.
Se l'entity assume il significato di semplice contenitore di dati, poi posso riutilizzarla meglio in molti più contesti e posso scambiare tra i vari livelli dell'applicazione un oggetto più leggero che non si porta dietro legami con la base dati.
Altro problema che riscontro è la possibilità che venga saltata la logica di business dell'applicativo, ad esempio ci potrebbero esistere degli stati in cui un'operazione CRUD non è ammessa in quanto logicamente sbagliata per condizioni indipendenti dall'entity stessa. Come faccio ad averne il controllo se chiunque abbia un riferimento all'entity può eseguire tali operazioni? Dovrei aggiungere logica dentro l'entity per evitare queste casistiche?

Personalmente trovo molto meglio separare logica e metodi per il CRUD dall'entità che rappresenta i dati

[Otaking]

beh il discorso è anche che...se te hai delle delle classiche classi e poi hai le rispettive DAO per fare tutto quello che desideri con un DB, hai sempre ha disposizione le classi base per poter lavorare su altri fronti (esempio NON su un DB).
Se metti tutto nelle entity, rischi di dover poi apportare delle modifiche devastanti... mentre con Hibernate/Dao metti le mani avanti per una gestione più pulita, ottimizzata, pronta per del refactoring, ecc...

[zakmckraken]

Giusto per rompere le scatole, carinissimo hibernate, ma se uno deve fare cose meno che semplici inizia ad impazzire con le dipendenze, con i bags, liste collezioni, oggetti che si tirano dietro mezzo database, documentazione mai chiara per le soluzioni che servono..
Ora, lo uso anche io, ma giusto quando mi trovo con un database da 15-20 tabelle max con db di 80/100 Mb ma non mi sognerei mai di andare oltre...

Giusto un opinione, attendo conferme o smentite (anche perche vorrei capirlo meglio sto oggetto blasfemo :P )

[khelidan1980]

ma se un applicazione è pesantemente data-centrica imho tanto vale buttarsi sul pl/sql

[MEMon]

Giusto per rompere le scatole, carinissimo hibernate, ma se uno deve fare cose meno che semplici inizia ad impazzire con le dipendenze, con i bags, liste collezioni, oggetti che si tirano dietro mezzo database, documentazione mai chiara per le soluzioni che servono..
Ora, lo uso anche io, ma giusto quando mi trovo con un database da 15-20 tabelle max con db di 80/100 Mb ma non mi sognerei mai di andare oltre...

Giusto un opinione, attendo conferme o smentite (anche perche vorrei capirlo meglio sto oggetto blasfemo :P )

Io sto iniziando ora, le potenzialità sono enormi ma come primo approccio non è dei più semplici.

[zakmckraken]

ma se un applicazione è pesantemente data-centrica imho tanto vale buttarsi sul pl/sql
Se pero'deve essere pure portabile so'problemi :P Spesso e volentieri mi sono trovato meglio a gestire la costruzione delle queries con oggetti Java/C#/C (vedi come hanno fatto in Php4Application, giusto per dare un esempio). E'un altro approccio chiaramente, ma se non altro ho pochi (1) posto dove fare le modifiche :P

Zak