.NET[DataSet vs DataReader]

[Scare360]

.NET introduceert een disconnected model m.b.v. DataSets. Nu ben ik met gedistribueerde componenten bezig en gebruik om aan de n-tier architectuur te voldoen DataSets. Nu de applicatie uit de klauwen begint te lopen krijg ik problemen met de performance, met name op de DataSets aangezien ik deze altijd gebruik OOK in read-only gevallen.

Wie heeft dezelfde ervaringen of kan mij aangeven waarom precies voor DataSets (disconnected) of DataReaders (session, connected) gekozen te hebben en in welke gevallen uiteraard.

Ja destijds heb ik in mijn C# Unleashed book opgepikt DataReaders te gebruiken voor read-only cases.

Ps: Dit artikel heeft mijn interesse gewekt om wat praktijk voorbeelden te evalueren op GoT http://www.c-sharpcorner....QLDataReaderVSDataSet.asp.

[whoami]

Ik dacht ook eens gelezen te hebben dat je het best DataReaders gebruikt voor read-only gevallen, aangezien een datareader eigenlijk niets afweet van de achterliggende data. (Althans, dat is wat ik ervan begrepen heb).

Een DataSet kun je dan wel weer gebruiken om de data uit te lezen en terug te gaan saven.

[Verwijderd]

DataReader is alleen nuttig in 2-tier stateful applicaties of binnen de datatier zelf. Een DataReader ( wat een open dataverbinding is!) buiten de data-tier brengen levert problemen op, want je helpt voordelen van n-tier development om zeep. Je moet imho dus de keuze maken: OF n-tier development, en dus tiers als black boxes met een disconnected behaviour, OF een alles-in-een tier zonder black boxed layers.

Hieronder een rijtje uit mn artikel over n-tier development in de LLBLGen documentatie. Deze punten haal je niet met een open database verbinding die tussen tiers heen en weer wordt gesjoeld:

• Functionality separation. Because each layer has a well defined role in the total application, the system designers plus developers know where which functionality should be implemented or is located.
• Functionality reuse. Because each tier provides a service to the layer(s) on top of it, different layers or tiers or even complete other systems, can use that particular layer to provide some services for them. This is the basis for the Webservices idea.
• Functionality abstraction. By defining parts of an application's logic as tiers, you can hide how that tier provides its services for the rest of the application. This is particular useful when the application has to grow in functionality. By keeping the interface of the tiers consistent (or at least backwards compatible) the users of those interfaces, other tiers, will keep working when the tier's inner logic itself is updated and even totally rewritten.
• Functionality scalability. Because the tiers are separate units, you can decide to run each tier in an application on different machines, to keep the system scalable when the load on the application grows. When an application consists of one big executable, it's hard to chop it up into separate blocks and run each of them on different servers or even clusters of servers.
• Functionality maintainability. Because the functionality can be reused, it can also be centralized, so instead of storing all the logic in one big client and installing that on hundreds of machines, you can now store all the logic in one tier on a central server and make the clients connect to that tier on that machine to consume its services. This way a single place of functionality has to be controlled and maintained. The extra bonus of this is that the databases behind that centralized tier are also shared among those clients, which means that database-redundancy and the unavoidable inconsistency between these redundant databases are history. This is the main goal for Webservices.

IMHO zijn datareaders een vrij overbodig component, temeer omdat in pure n-tier applicaties je geen datareaders gebruiken KUNT, gewoonweg omdat tiers dan functioneel samensmelten omdat je de abstractie die je creeert door juist alles in een afgeschermde tier te plaatsen, weghaalt.

[tijn]

paulgielens schreef op 02 september 2002 @ 18:55:
.NET introduceert een disconnected model m.b.v. DataSets. Nu ben ik met gedistribueerde componenten bezig en gebruik om aan de n-tier architectuur te voldoen DataSets. Nu de applicatie uit de klauwen begint te lopen krijg ik problemen met de performance, met name op de DataSets aangezien ik deze altijd gebruik OOK in read-only gevallen.

De laatste tijd zie je in samples steeds meer dat ze ipv datasets lichtgewicht custom classes gebruiken (check bijvoorbeeld de source van het forum op http://www.asp.net). Deze worden in de data access layer gevuld met behulp van datareaders. Deze methode schijnt goed te schalen en maakt daarnaast een mooier OO ontwerp mogelijk . Helaas mis je op deze manier wel een hoop leuke dingen die je met datasets kunt uitvreten.

[ Voor 0% gewijzigd door tijn op 02-09-2002 20:37 . Reden: Overbodig gezwam ]

[Scare360]

Ja ik gebruik dus nu 100% DataSets over de tiers, maar ook intern (dirty). Dit was eerder om consistent te blijven dan om de code tot in den treure door te optimaliseren. Dat n-tier disconnected moet zijn (zou moeten zijn ) is mij bekend... stateless vanzelfsprekend. Punt is dat ik in de war was door de reader voor read-only access. Voor data over de tiers of xml of DataSets. Binnen de tier is een DataSet nog de beste keuze imo om de recources gelijk weer vrij te geven.

[Verwijderd]

tijn schreef op 02 september 2002 @ 20:35:
[...]
De laatste tijd zie je in samples steeds meer dat ze ipv datasets lichtgewicht custom classes gebruiken (check bijvoorbeeld de source van het forum op http://www.asp.net). Deze worden in de data access layer gevuld met behulp van datareaders. Deze methode schijnt goed te schalen en maakt daarnaast een mooier OO ontwerp mogelijk . Helaas mis je op deze manier wel een hoop leuke dingen die je met datasets kunt uitvreten.

Die source van asp.net is wanordelijk complex. Verder schalen datareaders totaal niet, omdat je een open connectie open houdt over meerdere tiers, wat inhoudt dat je 1 tier van 2 of 3 tiers maakt. Wat inhoudt dat je in feite 1 app hebt, en dus geen schaalbare n-tier oplossing.

[tijn]

Verwijderd schreef op 02 september 2002 @ 22:57:
[...]

Die source van asp.net is wanordelijk complex. Verder schalen datareaders totaal niet, omdat je een open connectie open houdt over meerdere tiers, wat inhoudt dat je 1 tier van 2 of 3 tiers maakt. Wat inhoudt dat je in feite 1 app hebt, en dus geen schaalbare n-tier oplossing.

Ik ben het met je eens dat die source aan de complexe kant is, maar als je goed kijkt kun je er wel degelijk een 4-lagen structuur uithalen, waarbij de datareaders NIET over meerdere tiers gebruikt worden, alleen in de DAL om de custom classes te vullen. Wanneer je datasets gebruikt die je vult in de DAL komt dit in principe op hetzelfde neer (intern wordt er ook een datareader gebruikt om de dataset te vullen via de data adapter), maar vermijd je een stuk overhead die datasets met zich meebrengen.

[Verwijderd]

Via een dataadapter een datatable vullen en die doorpassen naar hogere tiers komt op hetzelfde neer als een eigen class maken, daar rijen e.d. in bouwen en die vullen met data uit een resultset gelezen met de data-reader IMHO ben je echt sneller klaar met die 2 regels code die middels de data-adapter en de datatable de tabel vult dan de bakken met code die een custom class vullen met data.

[tijn]

Verwijderd schreef op 03 september 2002 @ 13:29:
Via een dataadapter een datatable vullen en die doorpassen naar hogere tiers komt op hetzelfde neer als een eigen class maken, daar rijen e.d. in bouwen en die vullen met data uit een resultset gelezen met de data-reader IMHO ben je echt sneller klaar met die 2 regels code die middels de data-adapter en de datatable de tabel vult dan de bakken met code die een custom class vullen met data.

Hehe, ja maar je moet natuurlijk niet een dataset willen nabouwen met je custom classes .
Het mooie van custom classes is dat ze in principe volledig los van je database staan en een veel mooiere representatie van de werkelijkheid geven (ik ga altijd uit van de business layer en werk daarna door naar data en presentation).

[Scare360]

Verwijderd schreef op 03 september 2002 @ 13:29:
Via een dataadapter een datatable vullen en die doorpassen naar hogere tiers komt op hetzelfde neer als een eigen class maken, daar rijen e.d. in bouwen en die vullen met data uit een resultset gelezen met de data-reader IMHO ben je echt sneller klaar met die 2 regels code die middels de data-adapter en de datatable de tabel vult dan de bakken met code die een custom class vullen met data.

Nou... voor web is dat inderdaad niet direct vereist MAAR zodra je echt de apps ingaat en het dus verder gaat dan data weergeven en de mogelijkheid geven INSERT/UPDATE/DELETES te doen op de data. Voor mijn FrameWork vertaal ik een relationeel datamodel...dus de DB naar een objectmodel zodat de proggers die de componenten ontwikkelen gewoon objecten kunnen aanspreken en gebruiken zonder er over na te denken dat op de achtergrond alles in een SQL db opgeslagen wordt.

Een... voorbeeldje... een bin is een virtueel vat met een inhoud, bv graan welke opgenomen worden in een tabel bins_bin. In het FrameWork:

code:

DAL: bin_bins(LLBLGen klasse met SELECT, INSERT, UPDATE, DELETE)
BLL: Bin(een bin object), BinManager(managed bin objecten... dus loaden,
saven etc. Hier is een Collection met bins voor handen.
Via een event systeem worden de bins automatisch verwerkt inde database)
BF: BinStocks (logica voor beheren voorraad)
USL: GUI voor de BF

De progger van de BF kan boven op het FrameWork dus aanvullingen schrijven. Hier werk je dus met objecten ipv relationele data. Maakt het leven makkelijker en het FrameWork is schaalbaar op de BLL, DAL tiers.

[Verwijderd]

paul: edit dat code blok ff, want die wrapt niet en dat leest wat kloot'n

Typed objects werkt uiteraard makkelijker. Echter in de DAL zou je daar niet mee bezig moeten houden, wel in bv de BL support layer op de DAL en onder de BL, die bv de DAL retrieved datasets/tables omzet in classes. Vergeet niet dat datatables uniform zijn en de data zodoende in meerdere hoedanigheden gebruikt kan worden, wat soms ook een pluspunt kan zijn.

[Scare360]

Verwijderd schreef op 03 september 2002 @ 22:22:
paul: edit dat code blok ff, want die wrapt niet en dat leest wat kloot'n

Typed objects werkt uiteraard makkelijker. Echter in de DAL zou je daar niet mee bezig moeten houden, wel in bv de BL support layer op de DAL en onder de BL, die bv de DAL retrieved datasets/tables omzet in classes. Vergeet niet dat datatables uniform zijn en de data zodoende in meerdere hoedanigheden gebruikt kan worden, wat soms ook een pluspunt kan zijn.

Heb jij enig leeswerk aan te bieden, zodat ik me eens in kan lezen.

[Verwijderd]

Hmmz, de DNA / n-tier articles op de MSDN, maar die zul je zelf ook wel gelezen hebben denk ik. De enterprise architect projects die bij VSEA zitten bevatten bv 5 tiers of meer, waarbij je facades hebt die in feite een soort transformatie layer zijn tussen 2 tiers. Ik heb geen idee of jouw VS versie die docs levert, maar die waren op zich wel verhelderend.

Verder is het meer gezond verstand: n-tier development is een idee maar met fuzzy grenzen: je bent niet hardcoded gebonden aan 'dit mag wel en dit mag niet'. Verschillende mensen hebben verschillende ideeen over n-tier development en daarbij valt steeds weer op dat de een erg streng is mbt grenzen van tiers en de ander dat niet zo vastomlijnd ziet en ze in elkaar over laat lopen waar nodig. Het is maar net wat het beste is voor jouw situatie: de wat strengere variant heeft voordelen en nadelen en de wat soepelere ook, die op een rijtje zetten en dan afwegen mbt je eigen situatie is altijd het beste.

Performance-wise zul je dat ook in jouw situatie moeten testen, maar grove richtlijnen zijn er altijd te geven, en die zijn je denk ik ook wel bekend.

[Scare360]

Dan houden wij er dezelfde gedachtengang op na...

[Verwijderd]

Datareaders zijn forwardonly en je kan er maar 1 tegelijk openen.
Ik gebruik zelf altijd datasets, alleen een datareader als ik even door een paar rows wil heen loopen met een for each op basis van de rows.count - 1.

Maar om niet te veel problemen te hebben met de datasets en datareaders ben ik nu bezig met mijn eigen DataFactory