multi tier zonder dataset

[Verwijderd]

Ok, ik heb het tropic multi tier applicatie in c# eens grondig doorgelezen, maar zit met vragen.

Ik heb llblGen code generator gebruikt die datatables terug geeft.
Hoe moet ik nu juist mijn business logic opbouwen?

ik heb drie klassen (layers)
Klanten (methodes: addKlant, deleteklant,getKlant,getAllklanten)
Klant (entiteit met private variablen en getters en setters)
dalKlanten(llblgen generated code)

Is dit nu de juiste manier om het te doen? wat moet ik met die datatables doen? want moet ik doorgeven aan mijn presentation layer? entities arrays of datatables of...

Wat wil ik doen: retrieve data van één tabel, retrieve data van meerdere tabellen, lijsten tonen + single records tonen + filteren + caching (eventueel, hoeft niet)

ik ben nu dus echt wel de kluts kwijt...
(ik heb echter veel artikels gelezen over dit tropic hoor, wel nog geen boek..)

Moet ik er gewoon maar aan beginnen en dit zelf oplossen of zitten nog mensen met dit probleem?

[whoami]

Wat is de taak van elk van die 3 klassen?

Je hebt genoeg aan een class dalKlant (die dus de data-logica bevat, toevoegen, verwijderen, ophalen van klanten in de database) een class klant die de business logica bevat voor een klant. Deze class verkrijgt z'n gegevens (en bewaart z'n gegevens) door gebruik te maken van de data-logica die in de dalKlant class zit.

[EfBe]

De code die LLBLGen genereert moet je zien als code die je gebruikt wanneer je het nodig hebt, dus wanneer je een lijstje wilt van records, dan roep je een select method aan en je krijgt je rows, je bindt de datatable aan het control dat het lijstje moet tonen en je ziet je lijstje.

Wil je data opslaan, dan roep je een of meerdere update/insert methods aan in de dal classes met de data die je van je gui krijgt. Dit kun je bv bouwen in een aparte class die door de GUI wordt aangeroepen en de DAL classes aanroept.

je werkt dus niet zozeer met entity classes maar met functionality classes. Dus je hebt geen 'Customer' class maar een 'CustomerManager' class die je bouwt en die aangeroepen wordt door de gui en DAL classes aanroept en data update.

Je moet niet de fout maken dat je eerst focussed op HOE je het gaat implementeren en dan pas WAT je gaat implementeren, maar eerst focussen op WAT je gaat implementeren (functionaliteit, en je omschrijft dus lijstjes retrieval, nou dat zijn dus je datatables) en dan HOE je dat gaat doen (wat voor code heb ik nodig, wat heeft LLBLGen al voor me gegenereerd, wat moet ik nog zelf bouwen).

* EfBe , LLBLGen bouwer

[Verwijderd]

Het probleem is dat ik een beetje in de knoei zit met mijn tabellen voor mijn talen (zie andere post van mij, enkele dagen geleden over multi languages)
productentabel bevat alleen de gegevens die niet in verschillende talen voorkomen(prijs,id,..)
en de productentekst tabel bevat alle gegevens die taal afhankeljk zijn.
Ik zou deze twee nu willen combineren in één entiteit.
Hoe begin ik hier dan best aan?

mijn processen zullen zijn:
lees productinformatie voor product x met als taal y
lees alle producten die voorkomen in categorie x met taal y
haal detail op van product x met taal y

haal detail op van product x met alle talen
verwerk product x (alle talen)

enz..

[EfBe]

Dat zijn een aantal queries waar llblgen geen code voor genereert. (want weet niet aan de hand van de database wat voor queries je allemaal wilt, een tabel met 3 FK's levert dan bv al 6 verschillende sp's op, mocht je dat willen).

Hij genereert geen joins, dus die code moet je met de hand bouwen, of je moet 2 queries bv uitvoeren en in memory de data combineren, dit is veelal niet zo snel qua performance. Je datamodel is wel een zeldzaam voorbeeld van hoe je er niet aan ontkomt om entiteiten over meerdere tabellen te verspreiden (of je moet denormaliseren, dus bv producten 'engels' en producten ' nederlands' bv gaan gebruiken, maar dat is niet zo efficient.).

Dus, OF custom queries bouwen in T-SQL, die dan aanroepen met code die ik hieronder beschrijf OF je leest 2 keer een row uit de database en combineert die in een eigen object.

Custom queries aanroepen doe je door een copy te maken van bv de Product class die is gegenereerd, je noemt die ProductCustom. Je kiest een method die lijkt op wat je wilt, bv SelectAllW<foreignkey>Logic. Verandert die method zodat je custom query wordt aangeroepen en verwijdert de rest van de code (behalve de members en de properties) uit de custom class. Naam aanpassen van de class en klaar. Zo loop je niet het risico dat wanneer je de classes opnieuw genereert, je je eigen code overschrijft.

Op zich valt het mee denk ik, maar je zult een paar queries met de hand moeten maken.

[Verwijderd]

en nog een vraag
de dal geeft dan datatables door
en wat geeft de business logic dan door naar de presentatie laag? ook datatables (dan speelt de business logic gewoon voor doorgeef machine ofwat? >> of extra laag van abstractie zodat je geen dal in je presentatie hebt?)

[EfBe]

Verwijderd schreef op 27 mei 2003 @ 15:46:
en nog een vraag
de dal geeft dan datatables door
en wat geeft de business logic dan door naar de presentatie laag? ook datatables (dan speelt de business logic gewoon voor doorgeef machine ofwat? >> of extra laag van abstractie zodat je geen dal in je presentatie hebt?)

Een BL laag die niets met de data doet is in feite een facade voor de dal. Ik bouw altijd wel zo'n laag want die laat ik dan DataView objects teruggeven die ik creeer mbv de datatables uit de dal en ik kan dan de heenweg naar de database ook samenvatten in simpelere objects (zodat ik in de gui bv niet met de transactionmanager ConnectionProvider moet leuren). Business Logic is niet de validatie van data in een schermpje, maar bv als dit + dit + dat + zus in 3 of 4 entities dan wordt dit kortingsveld +10 anders + 20 (noem maar iets). Lang niet altijd heb je dat voor alle entiteiten in je database nodig.

Wil je in je gui NIET werken met datatables/dataviews maar met classes, dan zit je tegen veel extra werk aan te kijken, want je moet dan ook bv databinding zelf gaan implementeren. (of met typed datasets werken, maar dat geeft weer het nadeel dat je de spullen daaronder niet kunt genereren).

[Verwijderd]

Ik ben bezig met een multi-tier project in C# en raad zeker aan de weg van datatables/dataviews op te gaan eens je aan de GUI begint. Custom entiteiten heeft me dikwijls veel problemen opgebracht.

[Scare360]

Custom entiteiten gebruiken voor complex domein probleem. Ik denk dat jouw probleem domein vraagt om typed datasets(ivm met de relaties). Gewoon recht toe recht aan prototype bouwen om de tradeoffs in beeld te krijgen.

[Verwijderd]

paulgielens schreef op 28 mei 2003 @ 00:03:
Custom entiteiten gebruiken voor complex domein probleem. Ik denk dat jouw probleem domein vraagt om typed datasets(ivm met de relaties). Gewoon recht toe recht aan prototype bouwen om de tradeoffs in beeld te krijgen.

In welke laag die datasets?
de dal?
efBe gaat content zijn

[EfBe]

JIJ moet ermee werken

[Verwijderd]

ik zal het maar inneens te goei doen zeker
allé, ik ga gewoon de twee uitproberen

voor een beperkt deelvan de site
is zien wat het beste werkt zeker!

[Scare360]

Ik zeg ook nadrukkelijk prototype Ik zie alleen maar "lees" in je functionaliteiten, dus EfBe zal zich ook wel kunnen vinden in mijn statement m.b.t. typed datasets. Ik ben pro custom entities en een domain-driven-design proces

[Verwijderd]

"verwerk product x"
is schrijven

[Verwijderd]

wat denken jullie van dit?!
http://aspnet.4guysfromrolla.com/articles/102302-1.aspx
lijkt mij wel intressant!

[Scare360]

Deze is beter "denk ik" http://www.codeproject.com/csharp/ComplexDataBinding.asp