[Java webapp best practice] DB connectie aanroepen in DAO

[Verwijderd]

Momenteel ben ik bezig met mijn eerste webapplicatie project na een lange tijd in Java. Ik gebruik het JavaServer Faces framework en pas het DAO design pattern toe, om schaalbaarheid te realiseren ten aanzien van de datasource (de verwachting is namelijk dat deze op termijn zal worden vervangen). Maar nu vraag ik mij het volgende af met betrekking tot een best practice.

De queries op de datasource (momenteel een MySQL database) worden gerealiseerd door de DAO's welke resultaten teruggeven aan de business logic met behulp van beans (simpele property holders met getters en setters en collecties). Maar waar roep ik nu de connectie aan? De connectie zal worden opgezet op applicatieniveau, maar is het dan good practice om deze connectie aan te roepen in de DAO, om vervolgens een statement daaruit te instantiëren, waarmee de query wordt uitgevoerd (dus de DAO's zijn de enige objecten die iets te maken hebben met de datasource)? Of is het netter om een referentie naar de connectie door de business laag mee te geven aan de DAO's?

[ Voor 4% gewijzigd door Verwijderd op 07-02-2007 09:03 ]

[Kwistnix]

Ik neem aan dat je het DAO pattern gecombineerd hebt met het AbstractFactory pattern, aangezien je database onafhankelijkheid wilt realiseren. Dan kan je de logica voor het beheren van connecties het best in je DAOFactory implementaties stoppen.
Toch is het volledig zelf implementeren van een DAL mb.v. het DAO pattern niet ideaal als je weet dat je op termijn een andere database gaat gebruiken, want er zit dan redelijk wat onderhoud aanvast. Ik denk dat het gebruik van een OR mapper, zoals Hibernate, een betere keuze is.

[ Voor 38% gewijzigd door Kwistnix op 07-02-2007 10:05 ]

[Ansur]

De business-laag niet moet weten hoe het aan de gegevens komt, zolang ze er maar aan komen. Laat dus je connectie managed worden door je dao's.

Bekijk het zo: nu werk je met een database. Mocht je voor één of andere reden flatfiles ofzo willen gebruiken, moet je enkel je dao-interfaces uitwerken voor die flatfiles. Je hebt in dat geval er niks aan dat de business laag je een connectie doorgeeft.

[Verwijderd]

FallenAngel666 schreef op woensdag 07 februari 2007 @ 09:07:
Ik neem aan dat je het DAO pattern gecombineerd hebt met het AbstractFactory pattern, aangezien je database onafhankelijkheid wilt realiseren. Dan kan je de logica voor het beheren van connecties het best in je DAOFactory implementaties stoppen.

Jazeker, dat ben ik wel van plan inderdaad. De AbstractFactory levert dan een specifieke factory voor de MySQL implementatie. Dus als ik het dan goed begrijp zal de MySQL factory ook de connectie beheren.

[Verwijderd]

Ansur schreef op woensdag 07 februari 2007 @ 09:12:
Bekijk het zo: nu werk je met een database. Mocht je voor één of andere reden flatfiles ofzo willen gebruiken, moet je enkel je dao-interfaces uitwerken voor die flatfiles. Je hebt in dat geval er niks aan dat de business laag je een connectie doorgeeft.

Dit vind ik een goed punt. In principe maakt het inderdaad niet uit waar de gegevens vandaan komen. Dat interesseert de business laag ook niet. Of ze nu komen uit een bepaalde database, een CSV bestand, een XML bestand of wat dan ook, het is niet de zorg van de business laag. Deze gedachtegang is eigenlijk al het volledige antwoord op mijn vraag . Thanks!

[Verwijderd]

Ansur schreef op woensdag 07 februari 2007 @ 09:12:
Bekijk het zo: nu werk je met een database. Mocht je voor één of andere reden flatfiles ofzo willen gebruiken, moet je enkel je dao-interfaces uitwerken voor die flatfiles. Je hebt in dat geval er niks aan dat de business laag je een connectie doorgeeft.

Het is natuurlijk wel verstandig om deze uitspraak enigszins te nuanceren vanwege de ongelooflijke 'highly unlikely' factor in je betoog. Je software ontwerpen vanuit de gedachtegang dat je het later eventueel zou willen aanpassen vervangen is simpelweg een foute insteek. Je software ontwerpen vanuit de gedachtegang dat je aandachtsgebeiden wilt scheiden is wel een correcte insteek. Het uiteindelijke resultaat van de twee verschillende insteken lijkt overigens wel op elkaar.

[JKVA]

Als je doel schaalbaarheid is, zou ik kijken naar connection pooling. Is ook in Tomcat prima te realiseren met commons-dbcp ofzo. Dan hoef je in je code ook niets te regelen.

In je DAO connecties openen en sluiten zou ik absoluut niet doen, want je wil al je DAO aanroepen in een transactie één connectie laten gebruiken. In een DAO factory kan het eventueel wel, zolang je maar die factory instantie hergebruikt.

[Verwijderd]

Ter informatie

Ik heb inmiddels het DAO inclusief abstract factory design pattern geimplementeerd met voor nu specifiek een inrichting voor een MySQL database. Het werkt erg super al zeg ik het zelf! De loginmodule werkt reeds, waarbij ik gebruik maak van een applicatiefilter op het pad 'secure' voor het testen van een geldige login bij iedere actie welke wordt uitgevoerd in de secure omgeving.

[Verwijderd]

JKVA schreef op woensdag 07 februari 2007 @ 09:46:
Als je doel schaalbaarheid is, zou ik kijken naar connection pooling. Is ook in Tomcat prima te realiseren met commons-dbcp ofzo. Dan hoef je in je code ook niets te regelen.

In je DAO connecties openen en sluiten zou ik absoluut niet doen, want je wil al je DAO aanroepen in een transactie één connectie laten gebruiken. In een DAO factory kan het eventueel wel, zolang je maar die factory instantie hergebruikt.

Ik maak inderdaad gebruik van commons-dbcp voor de connection pooling. Wat betreft dat openen en sluiten van connecties heb je een goed punt. Nu wordt dit inderdaad op het DAO niveau geregeld (per DAO methode aanroep wordt een verbinding geopend en gesloten).