[JAVA] Hoe om te gaan met databasequerys

[Verwijderd]

Beste programmeurs,

sinds een jaartje ben ik wat actiever bezig met java en dan voornamelijk jsp. Toch loop ik iedere keer tegen een kleine vraag aan. De lessen die ik op school heb gehad waren erg beknopt en in boeken heb ik het ook nooit echt kunnen vinden.

Wanneer ik een applicatie maak, die informatie uit een database weergeeft. Hebben ik mijzelf min of meer aangeleerd om een klasse te maken desnoods singleton die de databaseverbinding bijhoudt en ook alle querys uitvoert. Wanneer ik een de data uit een bepaald object wil opslaan in de database dan roept dat object een methode van de databaseklasse aan, waarin de sql-query wordt uitgevoerd. Na verloop van tijd zit mijn databaseklasse vol met querys en ik kan me niet voorstellen dat dat een nette manier is.

Mijn vraag is dus hoe ik met dit soort ontwerp om moet gaan. Kom aub niet met antwoorden als Hibernate gebruiken etc. Ik ben van mening dat ik eerst de java-principes goed moet begrijpen alvorens ik met dat soort spul ga werken.

[Nick_S]

Ik heb meestal een model (meerdere klasses, bijv. persoon, bestuurstaak, commissie). Voor elke klasse maak ik een DAO (Data Access Object) interface. Dit is een interface, met de CRUD methodes (Create Retrieve Update Delete) zonder enkele logica, gewoon wegschrijven en ophalen. De implementatie hiervan is bij mezelf hibernate, maar hier kun je ook makkelijk een JDBC implementatie van maken, met een superklasse, die je connectie beheert of een aparte ConnectionPool

Daarboven komt de bedrijfslogica laag, deze bevat de logica wie wat wanneer mag. Zo hou je logica en database gegevens ook gescheiden.

Ik hoop, dat je hier wat aan hebt.

[Verwijderd]

Ik hoop, dat je hier wat aan hebt.

In ieder geval bedankt, maar het klinkt me allemaal nog vrij wazig

[Verwijderd]

Waarom zelf doen als er frameworks voor bestaan Zoals het veel gebruikte hibernate.

[Alarmnummer]

Verwijderd schreef op dinsdag 19 april 2005 @ 09:53:
[...]
In ieder geval bedankt, maar het klinkt me allemaal nog vrij wazig

Dat valt best mee. Voor alle entiteiten die je in je systeem hebt (bv persoon en fiets), maak je objecten aan die zorgen voor de database communicatie. Deze objecten heten DAO`s (of Data Access Objecten). Deze objecten zijn verantwoordelijk voor de database communicatie. Jij ziet daar de methodes save,update,delete,findAllePersonenMetDikkeNeus, findAlleFietsenMetLekkeBand. etc etc. Op deze manier heb jij dus een scheiding aangebracht tussen de database toegangscode en de code die er gebruik van maakt.

Ik maak trouwens van Hibernate gebruik om de DAO`s de invulling te geven. En als je verder een beetje handig omgaat met class structuren kan je heel eenvoudig iets op zetten. voorbeeld:

code:

class PersoonDao extends HibernateDao{
     PersoonDao(SessionFactory factory){
         super(factory,Persoon.class);
     }
}

Meer code hoef ik niet in te typen voor een basis doa omdat de rest (save, findall, update, delete, insert etc) al in de HibernateDao zit. De HibernateDao is trouwens iets dat wij (het bedrijf waar ik werk) intern ontwikkeld hebben.

[ Voor 30% gewijzigd door Alarmnummer op 19-04-2005 10:00 ]

[Apie!]

misschien is dit plaatje wat duidelijker voor je?

http://java.sun.com/bluep...terns/Patterns/index.html

Verwijderd schreef op dinsdag 19 april 2005 @ 09:57:
Waarom zelf doen als er frameworks voor bestaan Zoals het veel gebruikte hibernate.

Nee, want hij geeft zelf al aan dat hij wil weten wat er gebeurt vorodat hij dignen als hibernate gaat gebruiken.

[ Voor 60% gewijzigd door Apie! op 19-04-2005 10:00 ]

[Thyzz]

Voor DAO, staat er op de java.sun site een stukje geschreven
http://java.sun.com/bluep...rns/DataAccessObject.html

Maar google kan je daar ook een heleboel over vertellen

hibernate: http://www.hibernate.org
Ik heb geprobeerd daar zelf ook aan te beginnen, maar daar moet je toch even wat tijd in steken en die tijd heb ik nog niet kunnen vinden

[ Voor 0% gewijzigd door Thyzz op 19-04-2005 10:00 . Reden: spuit elf ]

[Verwijderd]

Alarmnummer schreef op dinsdag 19 april 2005 @ 09:57:
[...]


Dat valt best mee. Voor alle entiteiten die je in je systeem hebt (bv persoon en fiets), maak je objecten aan die zorgen voor de database communicatie. Deze objecten heten DAO`s (of Data Access Objecten). Deze objecten zijn verantwoordelijk voor de database communicatie. Jij ziet daar de methodes save,update,delete,findAllePersonenMetDikkeNeus, findAlleFietsenMetLekkeBand. etc etc. Op deze manier heb jij dus een scheiding aangebracht tussen de database toegangscode en de code die er gebruik van maakt.

Als ik het goed begrijp maak ik op dit moment dus gebruik van 1, welliswaar misschien slechte, DAO. Namelijk mijn databaseklasse met all querys voor de hele applicatie. Deze moet ik dus opdelen voor iedere entiteit.

[Alarmnummer]

Verwijderd schreef op dinsdag 19 april 2005 @ 10:01:
Als ik het goed begrijp maak ik op dit moment dus gebruik van 1, welliswaar misschien slechte, DAO. Namelijk mijn databaseklasse met all querys voor de hele applicatie. Deze moet ik dus opdelen voor iedere entiteit.

Niets moet. Ik zou trouwens Sun hun advies met een vrachtwagen zout nemen. Ze zijn goed in het schrijven van specs, maar voor praktische toepassingen zijn hun oplossingen vaak veel te zwaar. Je moet dus zelf een bepaald balans zien te vinden tussen wat jij handig vind werken en tussen de voorgeschreven specs (en dat balans is ook afhankelijk van de complexiteit van de opdracht)

Persoonlijk zou ik het wel handig vinden aangezien je anders 1 object krijgt met zoveel methodes. En dan zou ik toch liever een paar kleinere objecten zien. En verder zou je ze wel van een overkoepelende class kunnen laten extenden zodat je alleen maar de specifieke code (voor Persoon of Fiets) nog hoeft te schrijven.

Ik zou verder ook kijken naar een OR-mapper zoals Hibernate (alhoewel er ook wel eenvoudigere OR mappers zijn) en niet zelf meer pielen met JDBC.

[ Voor 12% gewijzigd door Alarmnummer op 19-04-2005 10:13 ]

[Verwijderd]

Alarmnummer schreef op dinsdag 19 april 2005 @ 10:08:
[...]

Niets moet. Ik zou trouwens Sun hun advies met een vrachtwagen zout nemen. Ze zijn goed in het schrijven van specs, maar voor praktische toepassingen zijn hun oplossingen vaak veel te zwaar. Je moet dus zelf een bepaald balans zien te vinden tussen wat jij handig vind werken en tussen de voorgeschreven specs.

Persoonlijk zou ik het wel handig vinden aangezien je anders 1 object krijgt met zoveel methodes. En dan zou ik toch liever een paar kleinere objecten zien. En verder zou je ze wel van een overkoepelende class kunnen laten extenden zodat je alleen maar de specifieke code (voor Persoon of Fiets) nog hoeft te schrijven.

Ik zou verder ook kijken naar een OR-mapper zoals Hibernate (alhoewel er ook wel eenvoudigere OR mappers zijn) en niet zelf meer pielen met JDBC.

Thnx, ik denk dat als ik nu wat meer lees over dit onderwerp ik een heel eind ga komen. En wat betreft het pielen met JDBC. Ik heb tot op heden nog geen problemen gehad. Je haalt je data op uit een opbject en ramt de zooi met een simpele sql-query weg en andersom. Misschien voor de toekomst een keer.