Archief - [PROG][ALG] Pattern voor DB-mapping?

Het archief is een bevroren moment uit een vorige versie van dit forum, met andere regels en andere bazen. Deze posts weerspiegelen op geen enkele manier onze huidige ideeën, waarden of wereldbeelden en zijn op sommige plaatsen gecensureerd wegens ontoelaatbaar. Veel zijn in een andere tijdsgeest gemaakt, al dan niet ironisch - zoals in het ironische subforum Off-Topic - en zouden op dit moment niet meer gepost (mogen) worden. Toch bieden we dit archief nog graag aan als informatiedatabank en naslagwerk. Lees er hier meer over of start een gesprek met anderen.
p

passero

Legacy Member
Wat ik me afvroeg...
Ik ga direct beginnen met het ontwikkelen van een framework voor een project. Een vrij groot project met een vrij grote DB, veel tabellen.

Het framework zou eigenlijk gewoon da Data Access layer bevatten en de objecten die door de front worden gebruikt om die access layer aan te spreken.

Ik heb al gezien van mijn collega's dat die meestal voor hun DAL per tabel een klasse maken en voor de facade nog eens identieke klasse die dan de DAL aanspreekt. Dit om ervoor te zorgen dat de front de DAL niet rechtstreeks aanspreekt... zoals het dus moet.

Ik vroeg me nu dus af of er geen deftige patterns bestaan die dit probleem aanpakken... Hoe map je dus tabellen op klassen en hoe maak je die beschikbaar voor de front klassen. Dit ongeacht de taal...
Het zal wel in ASP.NET worden geschreven maar het ik heb enkel het idee nodig eigenlijk.
.

.Acku.

Legacy Member
p

passero

Legacy Member
Mja dat we per tabel een object maken... dat had ik ongeveer door
maar ik bedoel zo ook over een ontwerp hoe je de connectie met de DB legt, hoe je de communicatie tussen uw front klassen en DAL klassen doet gaan, gebruik je daar nog een midden laag voor, hoe ziet die er uit , zo die zaken
.

.Acku.

Legacy Member
Oddly genoeg heb ik dat net uigelegd in een andere thread:

.Acku. zei:
Album lijkt mij toch wel HET object in uw applicatie, daarnaast ook nog een AlbumFacade met AlbumDAO, en mogelijk een AlbumService zelfs.

Album: alle velden die je in een album hebt (titel, uitvoerder en mogelijk een lijst van AlbumTracks objecten)
Bvb: getTitle(), getId(), setTracks(List tracks)...

AlbumService: logica die interessant is voor je applicatie zoals albums vergelijken, albums opslaan, verwijderen, updaten, aantal tracks opvragen, tracks opvragen in random volgorde etc etc. Alles wat met Albums te maken geeft.
Bvb: findAlbumByTitle(Album, album, String title), randomizeAlbumTracks(Album), storeAlbum(Album), getAlbum(Integer id)

AlbumFacade: Object die uw bussiness logica van uw database scheidt, hier zet je de methodes om albums te peristeren, in een DAO (data access object) aanpak houdt dat niet mee rin als verwijzen naar uw DAO.
Bvb: storeAlbum(Album), getAlbum(Integer id), deleteAlbum(Integer id)


AlbumDAO: de eigenlijke code naar je database, de SQL statements om een op te halen, een toe te voegen ed.d
bvb: storeAlbum(Album), getAlbum(Integer id), deleteAlbum(Integer id)


Je merkt dat er heel wat gedelegeerd wordt: Store oproepen in de service roept store in de Facade die store roept in de DAO. Op die manier hoef je enkel nog met de service te werken, terwijl je later de database implentatie veilig kunt wisselen (een wijziging van een JDBC Sql DAO naar bvb Hibernate of EJB3 DAO) zonder uw bussiness logic te moeten hercoderen.

Je mag hier gerust de facade laten vallen als je wilt.

Als je zo werkt, werk je op degelijk niveau;)
Klik om te vergroten...

Is DAO pattern met een Facade die benaderd wordt vanuit de service-laag.

DAO zit al de DB-code, hmm, nja afhankelijk van met welke persistentiezaken je werkt ga je moeten zien hoe je je sessie en transacties gaat doen. Dat zit imo in de DAO logisch gezien, de implementatie is dan weer technisch verschillend
p

passero

Legacy Member
Dus eigenlijk is de Facade niets meer dan een controller waarbij de methoden er zo uit zien:

private void Persist(Album anAlbum)
{
AlbumDAO.persist(anAlbum);
}

Lijkt intressant
O

Ollie

Legacy Member
passero zei:
Dus eigenlijk is de Facade niets meer dan een controller waarbij de methoden er zo uit zien:

private void Persist(Album anAlbum)
{
AlbumDAO.persist(anAlbum);
}

Lijkt intressant
Klik om te vergroten...

persist is geen static method in uw AlbumDAO class mag ik hopen?

EDIT: hypothetisch gezien dan...
p

passero

Legacy Member
Waarom mag dat niet static zijn?
Het behandelt toch de transactie met de DB af, leest dus het Album object in en zet die om naar een insert, update statement of vult de parameters van de stored procedure in.

Of dacht je eerder dat AlbumDAO ook per veld een get en set functie had en wanneer je dan albumDAO.persist doet, dat hij die dan omzet? Dan moet je eigenlijk
AlbumDAO albumDAO = new AlbumDAO(anAlbum)
albumDAO.persist();
doen.
O

Ollie

Legacy Member
passero zei:
Waarom mag dat niet static zijn?
Het behandelt toch de transactie met de DB af, leest dus het Album object in en zet die om naar een insert, update statement of vult de parameters van de stored procedure in.

Of dacht je eerder dat AlbumDAO ook per veld een get en set functie had en wanneer je dan albumDAO.persist doet, dat hij die dan omzet? Dan moet je eigenlijk
AlbumDAO albumDAO = new AlbumDAO(anAlbum)
albumDAO.persist();
doen.
Klik om te vergroten...

Het wordt aangeraden tegen interfaces te programmeren ipv tegen classes. Zeker als je wilt dat je DAO implementatie kan gewijzigd worden (gebruik van mock objects tijdens unit tests bijvoorbeeld of switch van JDBC naar Hibernate).

EDIT: voor iets meer informatie over het DAO pattern:

http://java.sun.com/blueprints/corej2eepatterns/Patterns/DataAccessObject.html
.

.Acku.

Legacy Member
Niet static, wel een shared singleton (Spring aanpak).
Kan wel wat verwarrend zijn als je een .NETTER bent, aanpak is vaak dezelfde maar termen en tools wat anders :)
e

eniac

Legacy Member
Ik heb weinig ervaring met dit specifiek, maar heb dit jaar in de lessen Ontwerpen wel kennis gemaakt met het Hibernate framework. Misschien iets dat hier van toepassing kan zijn?

Als ik er compleet naast sla, excuseer mij dan, zoals ik al zei: ik ben niet echt ervaren in deze materie.
M

Moto

Legacy Member
pfff interfaces en facades :sleep:
tijdverspilling noem ik dat :p
als ge het op het einde van het project die kunt refactoren misschien wel ja :p

En voor 1 tabel 1 klasse, vrij dwaze regel, moet ge per tabel bepalen.

Belangrijkste regel, hou het simpel :D

anyway ge hebt idd data access patterns :)
O

Ollie

Legacy Member
Moto zei:
pfff interfaces en facades :sleep:
tijdverspilling noem ik dat :p
als ge het op het einde van het project die kunt refactoren misschien wel ja :p
Klik om te vergroten...

Ik kan mij geen grotere tijdverspilling voorstellen dan het refactoren van slecht gedesignde applicaties...die je van de eerste keer goed had kunnen designen.
a

azerty

Legacy Member
NHibernate, lijkt me ook zeer interessant. Ik heb dat al eens gedowned en wat mee gespeeld en vraag me af wanneer M$ zelf met zoiets op de proppen gaat komen, of is het LINQ project hiervoor hun oplossing ?

Wat betreft NHibernate, is dat wel te betrouwen ? (kwestie van support,...) of is het eerder een probeersel, iets tijdelijks, effe een port van Hibernate naar dotnet zomaar om te proberen ?
.

.Acku.

Legacy Member
Moto zei:
pfff interfaces en facades :sleep:
tijdverspilling noem ik dat :p
als ge het op het einde van het project die kunt refactoren misschien wel ja :p

En voor 1 tabel 1 klasse, vrij dwaze regel, moet ge per tabel bepalen.
Klik om te vergroten...

Gij werkt duidelijk niet in een professioneel circuit ;)
M

Moto

Legacy Member
Ik kan mij geen grotere tijdverspilling voorstellen dan het refactoren van slecht gedesignde applicaties...die je van de eerste keer goed had kunnen designen.
Klik om te vergroten...
Wat ik dus bedoelde: In laatste versie van .Net kunt ge uw interface aanmaken door refactoring

Gij werkt duidelijk niet in een professioneel circuit
Klik om te vergroten...
Werk al 6,5 jaar als IT-consultant :woohoo: (en nee, geen kleine pruts-projecten :p)

-Ik heb dus al heel wat ervaring met slechte frameworks, die hopen classkes en interfacekes en facadekes genereren voor het minste.
-Ik heb dus ook al heel wat ervaring met mensen die denken dat ze enkel via patternkes en interfacekes en facadekes een 'professionele applicatie' kunnen creeeren zonder eerst na te denken als ze het wel echt allemaal nodig hebben (pseudo-architects :) )

Interfaces/facades zijn wel leuk als ge met twee teams zit, en ge goede afspraken wilt hebben over hoe de delen met elkaar communiceren
En als daar een deftige technische documentatie van is.

De beste regel die ik ken is, hoe simpler, hoe beter of KISS :p
Alles dat erin komt moet effectief nut hebben, als ge de zaken gaat complexer maken dan dat ze nodig zijn, dan zijt ge gewoon niet goed bezig
en dan bedoel ik dus ECHT nodig
.

.Acku.

Legacy Member
Een mens vrqqgt zich af wat voor projecten en voor wat bedrijf, maar na uw uitlatingen hier zou het onwijs van u zijn dat nog publiekelijk te zeggen.
Ge komt toevallig niet uit VB en ASP wereld zeker? Daar ken ik er zo veel die zoals u programmeren. Seniors in hun gebied zonder enig pattern te kennen.
M

Moto

Legacy Member
:sleep:

Ge komt toevallig niet uit VB en ASP wereld zeker?
Klik om te vergroten...
Heb altijd MS gedaan, 6,5 geleden was er nog geen .Net dus deed ik toen idd VB.
Wilt dus zeker in uw bekrompen I-Love-OO-&-Pattern wereldje zeggen dat ik er niks van weet :rofl:

Daar ken ik er zo veel die zoals u programmeren
Klik om te vergroten...
Hoe programmeer ik dan? Hebt ge ooit al code van mij gezien? Beschuldigt gij altijd mensen zomaar zonder te weten waarover ge praat?

Seniors in hun gebied zonder enig pattern te kennen.
Klik om te vergroten...
Heb in .net al genoeg patterns gebruikt ze :p
maar zoals ik al zei -> daar waar ze echt nodig zijn.
Als ge eens eerst zou leren lezen, dan zou ge weten dat ik niet anti-pattern ben. ik weet wel dat er altijd wel mensen zijn die zich een beetje teveel laten meeslepen in de alles-OO-gekte.
Tis niet dat ge dat GOF-boekske hebt gelezen dat ge dan ook elk pattern in uw applicatie MOET steken (staat ook in het boek zelf als ik mij niet vergis)

Ander voorbeeld zoals hier in de topic groot project
Waarchijnlijk een 20 tal code-tabellen
Als die niet hoeven geupdate te worden dan toch nog altijd vasthouden aan het 1 table 1 class principe?
Met businesslayer + datalayer en facades zijn dat dus 76 classes die ge meer maakt :p

Trouwen aan de topic-starter, hier is er een boek dat over data-patterns gaat, gewoon via bedrijf bestellen heh ;)

Patterns of Enterprise Application Architecture
By Martin Fowler, David Rice, Matthew Foemmel, Edward Hieatt, Robert Mee, Randy Stafford

Publisher : Addison Wesley
Pub Date : November 05, 2002
ISBN : 0-321-12742-0
Pages : 560
.

.Acku.

Legacy Member
Codetabellen access je niet met een object mapping per tabel, wel via een facade die dan delegeert naar de juiste tabel via meegegeven mapping, aangezien codetabel op zich gewoon 1 geheel is met logische onderverdelingen.

Twintig is niet eens zo grootschalig ;)

Nu goed, ieder zijn ding. Doe zoals je wilt, het irriteert me gewoon wat dat je zo mensen niet laat kennismaken met geavenceerde en veel gebruikte werkpatronen.
a

azerty

Legacy Member
Effe een vraagske tussendoor, veronderstel dat ik iets gelijkaardig wens te doen als den threadstarter, maar dan in Coldfucion met gebruik van CFC's. (cf components). Bestaat er daar al tool voor ?
Het archief is een bevroren moment uit een vorige versie van dit forum, met andere regels en andere bazen. Deze posts weerspiegelen op geen enkele manier onze huidige ideeën, waarden of wereldbeelden en zijn op sommige plaatsen gecensureerd wegens ontoelaatbaar. Veel zijn in een andere tijdsgeest gemaakt, al dan niet ironisch - zoals in het ironische subforum Off-Topic - en zouden op dit moment niet meer gepost (mogen) worden. Toch bieden we dit archief nog graag aan als informatiedatabank en naslagwerk. Lees er hier meer over of start een gesprek met anderen.
Terug
Bovenaan