Visualizzazione dei risultati da 1 a 4 su 4
  1. #1
    Utente di HTML.it
    Registrato dal
    Apr 2008
    Messaggi
    18

    Jdo-jdbc levatemi qualche dubbio

    Continua il mio giro di guide e documentazioni ma volevo fermarmi e capire quanto ho effettivamente assorbito e quando invece non mi è ancora chiaro.

    Java databse object(JDO) dovrebbe essere l'API per dialogare con un database orientato agli oggetti mentre jdbc per dialogare con un database relazionale come ad esempio mysql.

    Dovendo programmare ad oggetti in jsp un metodo che si addice a quello che avevo pensato mi par essere il definire nel database una serie di tipi (UDT) corrispondenti a mie classi per poter quindi estrapolare dal database non la singola stringa o intero, valore di questa o quella colonna(metodo che usavo programmando in php) ma proprio un oggetto da me definito.
    In questo modo il recupero poi dei valori corrispondenti a determinati attributi mi sembra molto più semplice e veloce.

    Chiarisco (più per me stesso :P ) con un esempio:
    - Definisco una classe Utente che dovrebbe contenere una serie di informazioni sull'anagrafica di un un utente.
    - Definisco il tipo nel Db con i vari campi(mica pochi).
    - Mappo la classe col il nome da me definito nel database in modo che poi faccià un cast automatico quando prelevo l'oggetto.
    - Manipolo l'oggetto come mi pare e piace
    - Vari ed eventuali update

    Vi risulta corretto?
    Tra l'altro avendo letto una guida un po datata volevo sapere se fosse un approccio ancora utilizzato o magari sostituito dall'api JDO e i database orientati agli oggetti.
    E nel caso quale è preferibile tra le due strade, ammesso che sia possibile confrontarle?
    Mi pare di aver letto che utilizzando jdbc mi perdo un po i concetti di poliformismo non realizzabili nei db.

  2. #2
    Utente di HTML.it L'avatar di Pastore12
    Registrato dal
    Oct 2008
    Messaggi
    1,051
    Io ho sempre usato le jdbc per collegarmi a MySQL e Oracle. Le JDO non le ho mai usate e non le conosco. Posso solo dirti che la prima via è certamente praticabile per i tuoi scopi, la seconda probabilmente anche..., ma se vai avanti tu poi dimmi come ti trovi
    "Ethics are to me something private. Whenever you use it as an argument for why somebody_else should do something, you’re no longer being ethical, you’re just being a sanctimonious dick-head"
    Linus Torvalds

  3. #3
    Utente di HTML.it
    Registrato dal
    Apr 2008
    Messaggi
    18
    Sbaglio o quello che ho appena detto non è praticabile con mysql che non definisce nuovi tipi?
    Effettivamente la guida che avevo letto faceva l'esempio di oracle.
    Database free che facciano questa cosa ce ne sono?
    O lascio perdere quest'ultima funzionalità ad oggetti e considero il database allo stesso modo di come facevo in php?

  4. #4

    Re: Jdo-jdbc levatemi qualche dubbio

    Sinceramente sono abbastanza niubbio di JDO ma se ho capito bene in realtà JDo può essere visto come uno strato intermedio tra le applicazioni Java e la connessione JDBC a DB relazionali.
    La forza di questa tecnologia è che è collegabile a diversi DB come ad esempio LDAP, XML, Execl e ovviamente a database relazionali come MySQL o Oracle.
    Al momento sto leggendo quello che trovo su un progetto interno ad Apache (datanucleus.org) che dovrebbe implementare questa tecnologia, peccato che ci sia qualche problema di compatibilità tra JDeveloper 10.1.2 e qualsiasi versione del suddetto progetto!!!
    Appena riesco a capirne qualcosa torno e ti faccio sapere
    Appena ne capirò qualcosa di più ti farò sapere
    Si dice che ci vuole un minuto per notare una persona speciale, un'ora per apprezzarla, un giorno per volerle bene, ...ma poi tutta una vita per dimenticarla.

    UN AMICO E' UN SOLE SENZA TRAMONTO...

Permessi di invio

  • Non puoi inserire discussioni
  • Non puoi inserire repliche
  • Non puoi inserire allegati
  • Non puoi modificare i tuoi messaggi
  •  
Powered by vBulletin® Version 4.2.1
Copyright © 2025 vBulletin Solutions, Inc. All rights reserved.