Verwijderd schreef op 16 April 2003 @ 22:31:
Mijn god EfBe, ik heb zelden zo'n arrogante en hooghartige verzameling reacties gezien als hierboven. DataSets zijn dom, DataReaders nog dommer, Microsoft is compleet de weg kwijt mbt persistence frameworks.... ja ja....
Het is mijn mening. Nu mag je mijn mening arrogant vinden, ik heb de afgelopen 4 maanden wel full time gespendeerd aan research op dit gebied naast het onderzoek van 3 maanden vorig jaar. En wellicht weet je het niet, maar iemands mening arrogant vinden is nog tot daar aan toe, maar dat als argument aandragen is wel erg triest.
Als je te dom bent om mee te praten over dit onderwerp, waarom hou je dan niet je mond, ipv hier deze thread te verstoren met je geklaag! Ik kan pagina's vol typen met argumenten voor mijn stelling, jij kunt alleen opperen dat ik arrogant ben. Ik word daar zo langzamerhand een beetje goed ziek van, dat wanneer je argumenten hebt die men NIET wil horen je arrogant bent. Kom met argumenten of hou je mond.
Nu inhoudelijk over je posting:
En dan Thomas Tomiczek aanhalen als referentie, de man is met zijn OR Framework een directe concurrent van ADO.NET / ObjectSpaces, nogal logisch dat hij deze niet bepaald de hemel in prijst! Hij zou nogal een dief van zijn eigen portemonnee zijn als hij iets anders verkondigde.
Laat ik voorop stellen dat Thomas en ik verre van vrienden zijn, en we verschillen fundamenteel van mening over wat voor patterns het beste zijn voor enterprise development. Dat neemt niet weg dat we allebei kunnen beargumenteren waarom we vinden wat we vinden.
Het dringt wellicht niet tot je door, maar ik weet echt wel waarover ik praat en Thomas ook. Beide waren we het er over eens dat DataSets een fout is van MS. En dat kunnen we allebei beargumenteren. Nu lijkt dat ineens niet meer objectief want zowel hij als ik maken generators voor persistence frameworks en zijn dus concurrent van MS en DUS hebben we ongelijk! Wat voor onzinnig wereldbeeld is dat, zeg! Het is je wellicht ontgaan maar allebei doen we dit werk al een lange tijd en spenderen veel tijd aan onderzoek op dit gebied en weten dus echt wel waarover we praten!
Bij mijn weten probeer jij ook met een of ander framework een stukje van de O/R persistence framework taart te verkrijgen, dus als ik JOUW argument gebruik tegen jezelf dan ben je zelf ook erg ongeloofwaardig.
Laten we eerst een paar dingen goed op een rijtje zetten: De versie van ObjectSpaces zoals deze tijdens de PDC 2001 gepresenteerd werd IS gebaseerd op DataSets, dus de stelling dat MSFT ObjectSpaces gaat vervangen door 'iets wat op DataSets gebaseerd is' vind ik een beetje vreemd.
Ik was zeer benieuwd naar objectspaces, want het klonk mij als the missing link in het geheel wat MS vorig jaar februari had gereleased in de oren. Echter is was het dermate prematuur dat het niet echt bruikbaar was en er ook weinig meer over werd gecommuniceerd door MS. In MS jargon heet dat: EOL, althans in die hoedanigheid. Gezien het succes van O/R mapping tools en persistence framework generators is het niet meer dan aannemelijk dat ze zo'n framework gaan aanbieden als aanvulling op bv Biztalk server, Commerce server en CMS server, of daar delen van implementeren op het persistence framework.
Objectspaces was volgens mij net als Olymars gestart binnen MS als testproject, is itt Olymars wel levensvatbaar gebleken en wellicht komt het ooit commercieel uit. Dat het op datasets is gebaseerd verbaast me niets.
Maar... waarom mag iemand dat niet een foute keuze vinden?
Dat het project al een tijdje 'stil' is wil niet zeggen dat het 'dood' is, het laatste bericht van het ObjectSpaces team in de nieuwsgroep melde ook duidelijk dat het project weer 'undercover' ging, wat er nog wel bij gemeld werd is dat we pas rond de PDC van (oktober) 2003 weer wat nieuws konden verwachten. Laat dat nou net ook de PDC zijn waar waarschijnlijk Yukon (SQL Server 2003/2004) en Whidbey (VS.NET 2004) gepresenteerd gaat worden! Toevallig! Aangezien Yukon de CLR in de database gaat integreren zul je daar waarschijnlijk compleet nieuwe manieren van data access zien, met de bijbehorende aanpassingen in System.Data (ADO.NET).
Ze zullen het wellicht op de PDC 2003 presenteren. Maar dat is wel veel te laat. Veel bedrijven die op enterprise niveau applicaties bouwen hebben of zijn bezig met de keuze voor O/R tools/persistence frameworks. Als MS in 2004 met zo'n framework komt, zijn de target klanten (dus de bedrijven die gerust 1000$ of meer per developerlicense betalen) veelal al voorzien van een toolkit die werkt en waar de developers mee om kunnen gaan EN die al een tijdje op de markt is.
Dat Yukon de CLR in zich heeft is fijn voor Yukon, maar ik zie daar niet het voordeel van in. Oracle ondersteunt al een paar jaar java in de database. Ik ken geen Oracle specialist die daar iets mee doet: ze schrijven nog steeds grote lappen PL/SQL, omdat ze weten dat dat werkt en goed performt. Het is ook een onlogische keuze, om bv je stored procedures in C# te gaan schrijven, botweg omdat je met sets werkt, en C# geen setbased language is. M.a.w: je zit altijd tegen een view-transitie aan te kijken, of beter: hoe je tegen je data aankijkt op tijdstip T, vanuit een zekere userspace U.
Een OO taal als basistaal gebruiken voor je relationele logica is een onlogische keuze. Database algebra is ook zelden uit te drukken in simpele imperatieve statements. Dat is niet voor niets zo.
Als MS vernieuwing zou willen brengen met Yukon dan moeten ze komen met een database die echt relationeel is, zoals Halpin beschrijft op zn website
www.orm.net. DAN ben je vernieuwend bezig en kun je de database engine als zodanig van meerwaarde voorzien dat developers daar veel voordeel uit kunnen halen. Nu wordt er suiker over de database engine gestrooid door de introductie van de CLR IN de database. Heeft IEMAND daar ooit een theoretisch kloppende verklaring voor weten te geven? Ik heb hem niet gezien.
Het lijkt mij dus zeer waarschijnlijk dat ObjectSpaces gewoon als 'EJB-killer' in Yukon gestopt gaat worden, misschien dat het dan alleen zal werken op Yukon, om de verkoop daarvan te stimuleren, maar het lijkt mij onwaarschijnlijk dat ze ObjectSpaces als apart product gaan verkopen.
Ik denk dat je dat verkeerd ziet. MS kijkt een beetje anders tegen de wereld aan dan Sun of IBM. MS heeft nl. producten als Biztalk server, een magistraal stukje engineering. Ze hebben dus al een BL-tier applicatie waar developers business logic in kunnen bouwen. Echter de input/output van data kan ook daar nog een hoop werk opleveren. Wat zou het dan goed zijn als je een framework had dat dus de I/O van data voor zn rekening neemt en daarmee mensen sneller in staat stelt om components voor biztalk te bouwen. Mind you: MS wedt niet op EJB achtige systemen, maar op webservices, dus het ziet een totaalweb voor zich van allerlei services die gekoppeld worden aan elkaar door verschillende systemen, zoals Biztalk server. De lijm daartussen is goed te gieten in een persistence framework, dat puur de data I/O regelt tussen die verschillende services.
Om terug te komen op de kritiek van EfBe: ik begrijp werkelijk niet waar dat op slaat. Als DataSets EN DataReaders niets zijn, wat wil je dan? Noem een een beter alternatief voor Data Access dan!
Je begrijpt er niet veel van geloof ik. WAT zei ik nu precies?
DataReaders zijn overbodig, WANT dataadapter doet wat je in 99 van de 100 gevallen ook doet bij een datareader: object vullen met data en dat object wordt gepassed naar andere tiers. DataReaders zijn ook ongewenst want ze zijn een open databaseconnectie en die wil je liever niet doorgeven over tiers, temeer omdat dat scalability teniet doet (als ik DAT ook nog moet uitleggen kun je beter deze thread verlaten).
DataSets zijn ongewenst in MULTI-USER applicaties. Ik heb expliciet aangegeven dat ze NIET ongewenst zijn in SINGLE-USER applicaties. Dit komt door de behandeling van state in een applicatie. In een SINGLE-USER applicatie is de applicatie state == de state hoe de enige user in het systeem die ziet, m.a.w., je kunt de state in het proces laden van die user. In een MULTI-USER applicatie echter heb je een andere omgeving: de applicatie state != de state hoe de user die ziet in zn eigen proces. M.a.w.: je kunt niet de applicatie state in memory laden. Je kunt ook niet in memory data wijzigen omdat in het proces van een willekeurige user niet een accurate afbeelding KAN staan van de applicatie state. Omdat je me toch niet gelooft en me toch weer arrogant gaat vinden even een voorbeeld:
Tabel T heeft op column C een unique constraint. C is niet lid van de PK. Users U1 en U2 werken afzonderlijk met de applicatie en gebruiken T. U1 voegt een row toe aan T met een nieuwe waarde voor C. U1 schrijft deze row weg in T in de database. U2 werkt met de in-memory rowset van T, T', in een Dataset DS en wijzigt daar een rij R. U2 wijzigt in R C zodanig dat het een nieuwe waarde krijgt, maar de UC niet schendt. Deze nieuwe waarde echter is de waarde die U1 voor C heeft weggeschreven in de nieuwe row die U1 aan T heeft toegevoegd. U2 heeft de wijziging voltooid, en omdat in T' voor C de nieuwe waarde niet voorkomt, slaagt deze wijziging. U2 stuurt de wijzigingen door naar de database echter, daar blijkt dat de nieuwe waarde voor R's C niet wordt geaccepteerd, want de nieuwe row ingevoerd door U1 bevat al de waarde voor C die U2 wil wegschrijven, wat de UC schendt en er dus een error volgt. U2 kan nu alleen maar de wijzigingen terugdraaien in DS voor R, wat extra overhead oplevert. Ook moet U2 opnieuw T' fetchen uit T in DS, want deze is gewijzigd. Echter dit is niet altijd zichtbaar voor U2.
Er zijn legio van dit soort voorbeelden te verzinnen, sommige zijn nog venijniger dan deze.
Wat is nu het geval? Een Dataset stimuleert dat je 2 keer je wijzigingen doorvoert. 1 keer in memory en 1 keer in de database. Omdat de wijzigingen in de dataset kunnen slagen en in de database niet, krijg je een patstelling wat te doen, immers je wijzigingen in de dataset zijn geslaagd. De enige conclusie echter die je kunt trekken is dat je pas kunt stellen dat je wijzigingen geslaagd zijn als BEIDE wijzigingen goed zijn doorgevoerd. Wat meteen de vraag oproept: waarom doe je dan niet 1 wijziging ipv 2, nl. direct in de database ipv eerst in de dataset? Verder redenerend kun je dan concluderen dat de Dataset als zodanig dus overbodig is, immers het impliceert dat je 2 keer een wijziging moet doen, (de 2e is impliciet) waarbij de 2e kan falen waardoor je de 1e moet terugdraaien, terwijl je dat dus kan vermijden, m.a.w.: een dataset compliceert de boel alleen maar.
Het wordt nog erger als in het voorbeeld hierboven U1 zijn dataset niet update met een WEL geslaagde update van U2 en verder werkt met de data in zijn huidige dataset. M.a.w.: Een dataset propageert het houden van (delen van de) applicatiestate in het user proces, terwijl dat dus niet de correcte applicatie state is, immers je werkt in een MULTI-USER omgeving.
Welnu, er zijn andere manieren om ervoor te zorgen dat je de problemen omzeilt die de dataset opwerpt: 1) direct wijzigen van application state waar deze wordt bewaard, 2) het ophalen van data uit de application state waar deze wordt bewaard in ALLE gevallen wanneer data benodigd is voor een zeker proces, en dus niet gebruik maken van gecachte data, behalve wanneer deze data in de application state read only is (bv lookup tables) en je absoluut zeker kunt zijn van de correctheid ervan op ELK tijdstip T.
1) gaat erg goed met dedicated stored procedure calls die aangestuurd worden door imperatieve code in bv een C# object. 2) gaat erg goed met DataTables en daarvan afgeleide objects, zodat je ze bv typed kunt maken, of bv DataViews.
Zo zie je, Looijmans, ik weet echt wel waarover ik praat en wat voor problemen er rijzen bij verschillende situaties. Mijn argumenten zijn niet uniek en niet nieuw, ze zijn al zo oud als ASP en ADO bestaan. Daar had je nl. EXACT dezelfde discussie tussen enerzijds mensen die open ADO Recordset objects gebruikten, daar rows toevoegden en die doorvoerden naar beneden en anderzijds mensen die disconnected recordsets gebruikten voor viewing/datareading en dedicated stored procedure calls gevat in imperatieve code voor modificatie van application state.
Ik doe dit werk al jaren en heb erg veel onderzoek gedaan naar de verschillende methodieken, temeer omdat je t.a.t. de beste methodiek moet gebruiken in het systeem waar je aan werkt. Ik vind het prima als mensen mijn argumenten ontkrachten met voorbeelden die aantonen dat ik ongelijk heb in juist de gevallen waarop ik mijn argumenten richt, graag zelfs, maar kom dan met wat meer aan dan dat je me
arrogant vindt of mijn mening
arrogant.
ADO.NET is een Data Access framework, geen business logic framework. De DataReader is gewoon een heel 'straight forward' manier om resultaten uit een DB terug te krijgen, de DataSet borduurt daar op voort en biedt bepaalde schaalbaarheids- en flexibiliteitsvoordelen vanwege zijn 'disconnected' opzet. Als jij DataSets als 'pure overkill' betiteld wil dat m.i. alleen maar zeggen dat je nog geen scenario tegen bent gekomen waar ze heel erg nuttig kunnen zijn.
DataReader kan heel nuttig zijn, maar binnen dezelfde tier/object waar deze wordt gecreeerd. Echter het zijn juist de scenario's waar een datareader naar een andere tier wordt doorgegeven die als 'voordeel' worden aangeduid en daar heb ik (hierboven nog een keer) bezwaren tegen geuit.
De voordelen van een dataset in het kader van disconnection van een set van data is ook van toepassing op een datatable en een dataview. De nadelen van een dataset zijn NIET van toepassing op een datatable en een dataview, omdat je daar geen rows aan toevoegt/wijzigt en die weer naar de database doorvoert middels een adapter.
De nadelen van een dataset zijn erg groot, zeker in het kader van een multi-user omgeving. Een developer die weet wat hij doet zal die nog wel omver kunnen programmeren ten koste van extra werk (de overhead uit het voorbeeld) maar omdat tools als visual studio.net en de niet aflatende stroom trieste cursussen in .net die datasets propageren als 'the way to go', zorgen er wel voor dat een groot deel van de 'developers' deze nadelen NIET ziet, maar er wel mee te maken krijgt wanneer het te laat is, nl, wanneer de applicatie in productie is en wanneer blijkt dat in de situatie van meerdere users de applicatie 'overklaarbaar' gedrag gaat vertonen.
Als JIJ nou niet zo arrogant was geweest en mij arrogantie had verweten, had ik je dit ook wel uit willen leggen hoor. Ik weet niet of jij 10 uur per dag onderzoek heb gedaan voor 4 maanden lang naar allerlei verschillende methodieken hoe je enterprise applicaties kunt bouwen zodat je je nieuwe generator daar volledig op kunt afstemmen, maar indien niet, wil ik je met alle liefde mijn bevindingen wel uitleggen. Tenslotte is het gebruiken van datasets 1 van de methodieken die mogelijk is. Omdat dit verre van ideaal is in een multi-user omgeving, is m.i. de Dataset een vrij overbodig geheel. Ik vind ook dat MS ipv een tool voor een typed dataset, een tool voor een typed datatable en typed dataview had moeten maken en wel IN visual studio.
In VS5 en 6 heeft hetzelfde zich afgespeeld: MS introduceert een methodiek die het makkelijk moet maken om forms met databases te verbinden. Op zich niets mis mee, maar om Fowler, mijn grote vriend, maar even aan te halen: "Where do you put your Business logic in such a model?", inderdaad, dat is erg lastig. Vandaar dat die modellen in VS5 en 6 absoluut niet werkten, maar erger: de tools er dus ook niet waren om makkelijk het WEL goed en solide op te zetten, de tools die werden meegeleverd waren immers gericht op de methodiek die men niet wilde. In VS.NET is dit precies hetzelfde. Je kunt nu wel een class maken die gederived is van een enterprise services component, en daar je dataset/connection/adapter op slepen en zodoende je formpjes er makkelijk aan koppelen, maar het is niets meer dan versluiering van een probleem van dezelfde omvang: de intentie was het makkelijk maken van het koppelen van een formpje aan een database. Dat is met de dataset ZEKER gelukt. Echter, om het goed te gebruiken in business logic, en goed als in: "t.a.t. bewijsbaar correct", moet je dieper met de materie bezig en zit een dataset je in de weg, zie voorbeeld hierboven. Wat dus resulteert in het niet bruikbaar zijn van de tools in VS.NET. Dit heb ik echt als een afknapper ervaren want ik ben in maart 2002 een maand bezig geweest om uit te vogelen hoe een dataset effectief toch kon worden ingezet in n-tier applicaties zonder dat je de robuustheid van een database-oriented state management zou verliezen. Dat bleek m.i. niet mogelijk en gezien de hoeveelheid generators op dit gebied ben ik zeker niet de enige.
Je kunt het MSFT en ADO.NET moeilijk kwalijk nemen dat mensen deze technologie gebruiken om in VS.NET een GUI bij elkaar te slepen! Je kunt het MSFT hoogstens kwalijk nemen dat ze 'out of the box' geen business logic framework bieden in het .NET framework.
Ik vind het prima als mensen met wat sleur/pleur een GUI kunnen koppelen aan een database. Daar zijn RAD tools voor bedoeld tenslotte. Echter je moet ook niet uit het oog verliezen dat VS.NET niet bedoeld is voor louter de single-userapp knutselaars, maar ook voor de developers die zich richten op multi-user applicaties, zoals stateless webservices, webapplicaties etc.
Ik kan daar goed inkomen overigens, de argumentatie daarachter zal zijn dat ADO.NET de noodzakelijke basis biedt waarop een goede BLL gebouwd kan worden. Verder moet je niet vergeten dat we hier met 1.0 release te maken hebben, weliswaar een 1.0 release van zeldzame kwaliteit maar je kunt moeilijk verwachten dat het 'all things for all people' biedt, kijk eens hoe lang Sun erover gedaan heeft om met J2EE te komen, en dan praten we niet eens over het gedrocht dat EJB geworden is! Had je dat dan gewild soms?
Wat ik had gewild is dat MS MEER leerde van de fouten van het verleden. Als je kijkt naar bv Windows DNA, dan is er GEEN tool die je daarbij helpt op een RAD manier, althans niet van MS. Nooit geweest ook. Het is WEL hun idee. Ook VS.NET helpt je er nauwelijks mee. Het is of datasets of veel werk zelf doen. Iets zegt mij dan dat je niet goed hebt nagedacht over je tool. Dat het een 1.0 release is weet ik, ik vind elke dag nog nieuwe bugs (wacht met smart op vs2003 upgrade) die veel tijd kosten, maar goed c'est la vie.
Excuses voor de wat aangebrande toon in deze post, ik heb best respect voor je kennis en werk (LLBLGen) maar als we het dan toch over top 10's hebben dan sta jij door deze (en eerdere) posts wel in mijn top 10 van meest arrogante mensen!
Ik hoop toch wel op nr 1 dan toch?
Verder wil ik je vragen beter na te denken over wat wellicht mijn beweegredenen zijn om iets te zeggen. Ik ben t.a.t. bereid toe te geven dat ik fout zit met een redenering of dat mijn argumenten in een kleinere ruimte toepasbaar zijn dan ik wellicht stel. Maar ik vind het werkelijk stuitend dat ik als zeer arrogant wordt uitgemaakt en dan een post doorlees zonder 1 argument waarom ik ongelijk heb.
Ik ben nu een dik uur bezig geweest met deze posting, ik hoop dat het voldoende is als illustratie van mn argumenten. Zo niet, dan is dat jammer maar helaas.
[
Voor 9% gewijzigd door
EfBe op 17-04-2003 11:18
. Reden: typos/flames;) ]
:strip_icc():strip_exif()/u/1857/crop5a4d06ced6afe_cropped.jpeg?f=community)
(LLBLGen 
. Je kan daaroverheen een BL-facade layer definieren die het werken ermee makkelijker maakt, bv een typed datatable achtige constructie, of bv een serie objects per entiteit met handige 'save' methods. Persistence frameworks bieden veelal deze functionaliteit, echter sommigen gaan de fout in dat ze statechanges niet terugpropageren naar de database wanneer dat wel nodig is.
:strip_exif()/u/20832/Thigh.gif?f=community)
:strip_exif()/u/31626/eend.gif?f=community)
:strip_exif()/u/22119/ch.gif?f=community)