[alg/.net]DAL en BL met custom objects

[Verwijderd]

Voor ik begin aan mijn nieuw project wil ik toch eventjes vragen of dit wel de juiste manier van werken is.

Voor DAL gebruik ik LLBLGen (return't datatables)

voor de entiteit Huis heb ik bvb 3 klasses

Huis (entiteit zelf)-
HuisCollection (erf over van arraylist, kan ik eventueel weglaten)
HuisManager (hier gebeurd datamapping)

in huisManager heb ik static methods die dienen voor CRUD (maar op hoger niveau CRUD dan de DAL)

bvb

C#:

Huis huis = new Huis()
huis.naam = "bla";
huis.status= "verkocht";
Huismanger.add(huis)
Huiscolleciton lijst = new Huiscollection();
lijst = Huismanager.getLijst();//getLijst returnt dan die customCollection

In mijn systeem moet ik dan op een bepaald moment mijn datatable (van llblGen) omzetten in een customCollection: is dit datamapping dan? is dit de juiste manier van het te doen?

efBe, misschien kan jij me ook hier bij helpen?
Groetjes

[whoami]

Als je geen complexe Business Logica hebt, dan kan je -imho- ook gewoon de DataTables gebruiken in je presentatie-laag.

Stel dat je geen bewerkingen moet uitvoeren op die data, en dat je ze enkel wilt tonen en evt de data wilt aanpassen, dan vind ik dat je gewoon de gereturnde datatable kunt gebruiken.

[Woy]

whoami schreef op 15 juli 2003 @ 09:58:
Als je geen complexe Business Logica hebt, dan kan je -imho- ook gewoon de DataTables gebruiken in je presentatie-laag.

Stel dat je geen bewerkingen moet uitvoeren op die data, en dat je ze enkel wilt tonen en evt de data wilt aanpassen, dan vind ik dat je gewoon de gereturnde datatable kunt gebruiken.

Als het echt simpele data is ben ik het wel met je eens. Maar als het wat complexer in elkaar steekt waardoor je ook dingen als Lazy loading en dergelijke in wilt bouwen dan vind ik het toch netter om Business objects te gebruiken

[EfBe]

Je creeert zo wel veel overhead die je wellicht niet nodig hebt. Whoami geeft goed aan dat je alleen daar waar nodig extra functionaliteit moet bouwen. Dat is ook de insteek geweest van v1.x, waarbij je ervan uitgaat dat de entiteiten in de database staan en wanneer je die wilt bewerken je een bewerkingsmethod aanroept in de DAL. M.a.w.: er leeft niets in de BL, daarin zit louter functionaliteit. Je kunt met de datatables prima werken, het is alleen zo wanneer je echt op een hoger level wilt werken met de data, dus op entiteit niveau en met entiteit classes, je de conversie zelf moet doen, wil je v1.x gebruiken.

De Pro versie die (hopelijk) eind augustus uitkomt wordt dit ondervangen, maar daar heb je nu niets aan natuurlijk.

[Verwijderd]

"je de conversie zelf moet doen, wil je v1.x gebruiken. "
Dus zoals ik op dit moment bezig ben. Datamapping hoort dan toch thuis in je manager classe?

Dde graad van complexiteit is niet zo erg, alhoewel:

HuisTaal erft over van huis, dit erft over van vastgoed (in mijn klasse) >> anders moet ik elke keer mijn datatables bijeen spronkelen, nu slechts een keer!
(HuisTaal bestaat in database ook uit drie tabellen).

Maar mijn vraag is eigenlijk: moet je bij zo'n Domain pattern nog LLblGen gebruiken?:
stored pro's >> Datatables >> customCollection >> UI

[whoami]

Ik vind jouw uitleg een beetje vreemd:

'huistaal erft over van huis....' Wat is huistaal? Is huistaal dan een huis?

[Verwijderd]

huis erft over van vastgoed

huisadmin erft over van huis
huisTaal erf over van huis
in huistaal staat een string (of meerdere ) met de omschrijving etc in één specifieke taal
in huisAdmin staat een collection van talen, zodat de admin deze kan aanpassen

[whoami]

Ik denk dat je dat van die huistaal toch wel beter had kunnen oplossen hoor.....
Overerving om dit te implementeren vind ik ranzig. Je had evengoed die omschrijving (en alle andere 'tekst' die je in meerdere talen wilt laten weergeven) in resource-files gepropt.
Die kan je dan als satelitte-assemblies gaan compilen enzo en mbhv een resourcemanager haal je de gewenste string eruit.

Dat je huis overerft van vastgoed is goed. Een huis is immers een vastgoed. Echter, die zaken met die huistaal en admin enzo, vind ik gewoon ranzig en een slecht design.

[ Voor 19% gewijzigd door whoami op 15-07-2003 16:21 ]

[gorgi_19]

Erhm.. Een huisadmin is een verbijzondering van huis? Een huisTaal is een verbijzondering van huis?

Of heeft een huisadmin een huis?

[Verwijderd]

tis wel degelijk een verbijzondering :-)
(ja mijn naamgeving is nogal onduidelijk )

ik zit eigenlijk met de volgende tabellen: tblhuis,tblgrond,tblappartment, allemaal met een één op één relatie naar vastgoed (is gedenormaliseerd, ik kon ook nog twee apparte tabellen hebben voor mijn properties (grootte,slaapkamers) + values, maar ik doe dit niet wegens te complex) anyway:

Mijn omschrijvingen komen voor in verschillende talen
vastgoed_taal = associatieve entiteit van de relatie taal en vastgoed.

Vastgoed is dan een klasse
huis erft alles over van vastgoed(zoals prijs) + stelt aantal extra opties zoals aantal slaapkamers

in huisAdmin (erft over van huis) zit dan alles van huis + de teksten in de talen namelijk taalCollection(ik kan dit toch moeilijk in een recource file proppen >> waarvoor dient een database anders??)

in huisTaal (erft over van huis) zit gewoon een extra string voor omschrijving

ik maak een huis voor de klant aan in mijn UI
dim huis as new huistaal
huis = huistaalmanager.gethuis(id,taal)
txtomschrijving.text = huis.omschrijving

voor admin
dim huis as new huisadmin
huis = huisAdminManager.gethuis(id)
txtomschrijingNederlands.text = huis.omschrijving(0)
txtOmschrijvingFrans.text = huis.omschrijving(1)

Misschien is dit niet de beste oplossing, u mag mij raadt geven!
bedankt alvast om er over na te denken (wat ik zeker op voorhand al véél gedaan heb!)

[ Voor 89% gewijzigd door Verwijderd op 15-07-2003 17:06 ]