Rene Schrieken

Goede discussie, ik zal een aftrapje geven:

het is bekend dat het gebruik van DataSets flexibel is. Het werkt makkelijk en snel.
Maar deze hebben een performance overhead. Ze zijn tenminste 3x langzamer dan DataReaders.

Omdat het niet verstandig is om dataReaders over de tiers te verzenden (omdat de connectie met de DB open blijft staan) zullen zoals de titel van deze blog al aangeeft objecten gebruikt kunnen worden.

Niet voor niets wordt in de referentie applicatie van Microsoft data alleen opgehaald met DataReaders. Daarnaast wordt in de performance voorbeeld applicatie Petshop van Microsoft ook alleen maar datareaders gebruikt.

Voordelen van DS:
-ze zijn standaard serializable (heel makkelijk voor webservices) (maar objecten zijn dit evt. ook)
-Zijn eenvoudig te databinden aan bijv. een datagrid.
-zijn eenvoudig te cachen
-
-

Typed datasets zijn nog makkelijker in gebruik.
Maar moeten wel onderhouden worden. en hebben een nog grotere performance impact

We kunnen het ook nog over het updaten/inserten/deleten van data hebben.

de dataset kan gebruikt worden om dit soort functionaliteiten af te handelen icm dataAdapter. Dit werkt mbv een rowstatus.
de dataAdapter gaat alle rows af op zoek naar een bepaalde status en gaat per row indien nodig naar de database.
Het is op deze manier dus heel makkelijk om in 1x veel gewijzigde data naar de datalayer te sturen. Nadeel is dat dit alleen maar per table kan in de dataset. Ik zou zeggen dat dit soort gebruik alleen geschikt is voor Lookup tables.

NB:
In .NET 2.0 wordt het mogelijk dat er maar 1x een connectie wordt geopend naar de DB en alle wijzigingen in de data worden gedaan. in een soort van Batchverwerking.

Bij het gebruik van de Datareader zal de oplossing een array met objecten sturen.

Ik denk dat de keuze voor datasets / datareader moet liggen in de type applicatie die je moet ontwikkelen.
Lookup tables/onderhouds tabellen etc kan met datasets. Core business objecten met intensief gebruik, of als het bij een applicatie echt om performance gaat. Is het zonder twijfel nodig te kiezen voor dataReaders.

Bovenstaande zou mijn keuze zijn bij webapplicaties. Echter bij windows applicaties of een web/win (smart client) applicatie zou ik misschien toch wel datasets kiezen.

Voor het updaten van data zou ik niet snel (meer) kiezen voor de dataset, in plaats daarvan ouderwets properties meegeven of indien meerdere rows een array met objecten.

btw:
In .NET 2.0 komt er nog een andere manier bij: ObjectSpaces.

@Pascal: Over dat updaten per tabel. Je begint meteen daarna over .NET 2.0 en dat je daar met één connectie (?) naar de database in een batch alles kunt updaten.

Ik weet niet precies wat je bedoelt met je verhaal, maar als het gaat over dat je linked tabellen niet kunt updaten omdat je niet weet in welke volgorde. Bij mijn vorige project in Utrecht hadden ze daar wat op gevonden. Aan de hand van foreign-key contstraints kun je de volgorde bepalen van welke tabel als eerste naar de database gestuurt moet worden. Heb nooit naar het principe gekeken, zag alleen een naam die dat leverde.

ps. Jouw XP methods hebben zulke namen niet eens, en dit was zelfs helemaal uit gemodeleerd! ;)