[VB 2005] 1 dataset of meerdere dataset

[Verwijderd]

Ik heb de volgende vraag:

Ik ben op dit moment een applicatie aan het maken in Visual Basic 2005. Nu is het zo dat ik (zoveel mogelijk) gebruik maak van 1 dataset en daaronder datatables, queries e.d. definieer. Deze informatie gebruik ik dan in mijn schermen/forms.

Nu is het zo dat mijn collega alles op basis van een aparte dataset maakt. Verder dus geen queries definieert in de dataset maar voor elk scherm, of wat dan ook data ophaalt, een aparte dataset aanmaakt. Ik moet zeggen dat dit nogal 'tegen mijn gevoel' ingaat.
Ik heb al gezocht op het i'net en nog niet kunnen vinden wat nu beter/sneller is. De applicatie is nu nog niet zo groot dat we al verschil zouden kunnen merken.

Wat raden jullie aan?

[whoami]

Wat ik aanraad: niet met datasets werken, maar da's een ander verhaal.

Als je één dataset hebt, dan stel ik me er zo iets bij voor dat je uiteindelijk een groot deel van je DB in het geheugen gaat inladen. Dit gaat natuurlijk wel sneller, maar, je moet je natuurlijk wel de vraag stellen: 'zit je op ieder moment met de juiste gegevens ? '
Stel, je hebt 2 gebruikers, A & B.
Gebruiker A is aan het werken met bepaalde gegevens. Deze gegevens komen dus in je dataset.
Gebruiker B is ook aan het werken met bepaalde gegevens, en doet een update van bepaalde gegevens.
Gebruiker A heeft bepaalde gegevens nodig, en die gegevens zitten al in de dataset. Echter, die gegevens werden net door gebruiker B aangepast en gesaved in de databank. Welke gegevens krijgt gebruiker A voor z'n neus ? De correcte, door gebruiker B aangepaste gegevens, of de oude gegevens die nog in je dataset zitten ?

Een DataSet is imho een implementatie van het Unit of Work pattern; en naar mijn gevoel is je collega beter bezig: in zijn manier van werken heb je in ieder scherm een andere unit - of work. Je hebt op een bepaald scherm bepaalde gegevens nodig, past ze aan, en saved ze naar de DB. De UoW is afgelopen. Op een later moment heb je die gegevens opnieuw nodig, en haal je ze gewoon opnieuw uit de DB; je hebt zeker de recentste gegevens dan.

[ Voor 19% gewijzigd door whoami op 24-04-2007 17:55 ]

[Verwijderd]

Kijk daar heb ik nog eens wat aan! Bedankt voor je duidelijke antwoord!

[WasBak]

whoami schreef op dinsdag 24 april 2007 @ 17:53:
Wat ik aanraad: niet met datasets werken, maar da's een ander verhaal.

Het is misschien off-topic, maar ik ben wel benieuwd. Wat raad je dan aan?

Ik werk namelijk alleen maar met datasets.

[Verwijderd]

WasBak schreef op dinsdag 24 april 2007 @ 18:45:
[...]


Het is misschien off-topic, maar ik ben wel benieuwd. Wat raad je dan aan?

Ik werk namelijk alleen maar met datasets.

Dat vroeg ik me ook net af

[whoami]

Nouja, da's allemaal afhankelijk van de grootte v/h project, en wat de bedoeling voor dat project is. Voor een grote business applicatie zou ik zelf voor een 'rich domain model' kiezen icm een O/R mapper.
Dat heeft als voordeel dat je je eigen classes designed, en dus de mogelijkheid hebt om een 'expressief' model te creeëren.

Echter, in bepaalde andere gevallen zou ik dan zelf ook voor (typed) datasets kiezen.

[ Voor 81% gewijzigd door whoami op 24-04-2007 19:22 ]

[Verwijderd]

Eigenlijk is het vrij simpel. DataSets geven je geen mogelijkheden tot onder andere validatie. Business Classes wel. Daarnaast mixen DataSets de DAL met de BL (Als je die al gebruikt) en je wil die lagen graag scheiden. Buiten dat heb je ook nog de memory issues. DataSets worden gezien als groot en log qua geheugen (discutabel punt).

Naar mijn mening zijn datasets vooral geschikt voor wanneer je veel data moet combineren in rapportages/overzichten en/of grote hoeveelheden data in 1x moet manipuleren. In zulke gevallen kies ik of voor lightweight business classes of typed datasets. Ligt eraan of ik een OR Mapper gebruik. Bij manipulatie zal dit echter een afweging zijn die enorm van de omgeving afhangt, want eigenlijk wil ik alle data manipulatie gewoon in de business classes doen (waar het thuis hoort).

[ Voor 13% gewijzigd door Verwijderd op 24-04-2007 23:17 ]