Cookies op Tweakers

Tweakers maakt gebruik van cookies, onder andere om de website te analyseren, het gebruiksgemak te vergroten en advertenties te tonen. Door gebruik te maken van deze website, of door op 'Ga verder' te klikken, geef je toestemming voor het gebruik van cookies. Je kunt ook een cookievrije versie van de website bezoeken met minder functionaliteit. Wil je meer informatie over cookies en hoe ze worden gebruikt, bekijk dan ons cookiebeleid.

Meer informatie

[C#] Multi-tier applicatie

Pagina: 1
Acties:

  • pussher22
  • Registratie: april 2003
  • Laatst online: 11-06-2003
Ik heb zonet mijn eerste multi-tier programma achter de rug in Java (NetBeans). Nu moet ik een windows forms app ontwikkelen in C# (Visual Studio .NET).

Nu, in Java werkte ik zo:

- Data Access laag: hierin zaten alle methods insertStudent/getStudent/... die de sql statements uitvoerden op de db. Als parameters/returnwaarden gebruikte ik zoveel mogelijk de "databags" (klassen die een domeinobject voorstellen), zoals bv. "Student"
- Business/Transactie laag: hier checkte ik de verscheidene klasseninvarianten/business rules alvorens de method uit de DAL aan te roepen.
- Presentatie/GUI laag

Om data uit te wisselen tussen de verschillende lagen, voor te stellen op de GUI maakte ik dus zoveel mogelijk gebruik van die databags.

Nu, ik heb al wat kleine voorbeelden gevonden van multi-tier C# apps en daar wordt om data te transporteren, voor te stellen op de GUI (dataGrid) gebruik gemaakt van "DataSets". Aangezien ik niet bekend ben met DataSets vraag ik me af of dit dé manier is om multi-tier te werken. Ik was van plan terug te werken met databags, maar dan zie ik niet direct in hoe ik die bv. op mijn GUI zal kunnen weergeven. Misschien is het beter over te schakelen op "DataSets" om gegevens tussen de lagen te transporteren, maar is het dan nog nodig om terug complete databags te schrijven?

Dan nog kort iets over validatie: in Java werkte ik met een Access db en veel controle op db niveau was er niet (store procedures zijn mij vreemd). Er zat wat validatie op de GUI, maar de eigenlijke validatie gebeurde binnen de databags. Zo was ik zeker dat ik altijd met geldige objecten werkte, en dus ook geldige objecten wegschreef naar de db. Waar zou ik nu best de validatie plaatsen indien er geen databags meer zouden voorkomen?

Indien iemand een kleine voorbeel app heeft is die steeds welkom. Thx!

  • whoami
  • Registratie: december 2000
  • Laatst online: 08:07
Er zijn verschillende manieren om data te transporteren in .NET applicaties. DataSets is daar inderdaad één manier van. (Dan gebruik je het Table Module patroon dat beschreven is in het boek: 'Patterns for Enterprise Application Architecture' van Fowler).
Je kunt echter ook gewoon gebruik maken van je eigen objecten om de data door te geven. Om die data dan op je form weer te geven, kan je ook gebruik maken van databinding. Kijk daarvoor bv eens naar de DataBindings property van de UI controls.
(Wat je precies bedoelt met DataBags is me niet duidelijk, ik heb geen ervaring met Java).

Over de validatie:
Je kan op verschilllende manieren validatie gaan inbouwen. Zowel op de presentatielaag als op de datalaag en eventueel in de lagen ertussen.
Stored procedures zijn echt een must: ze zorgen voor performantiewinst en je kan er veiliger mee proggen. Natuurlijk moet je wel een DBMS hebben die dat ondersteunt. Access is trouwens geen geschikt DBMS voor enterprise applications.

DevLog - FotoLog


  • pussher22
  • Registratie: april 2003
  • Laatst online: 11-06-2003
Ff ter verduidelijking: een "databag" is gewoon een omschrijving van een klasse (vb. Student) die gebruikt wordt om data van 1 record bij te houden en te transporteren tussen de verschillende lagen. Binnen deze klasse zitten ook validatieregels (vb. controle op max. lengte naam student).

Wat betreft stored procedures, die lijken zeker interessant. Aangezien ik nu zal werken met MSDE zal ik die wel kunnen gebruiken, dus daar zal ik proberen ook iets over te vinden.

  • whoami
  • Registratie: december 2000
  • Laatst online: 08:07
quote:
pussher22 schreef op 15 April 2003 @ 10:46:
Ff ter verduidelijking: een "databag" is gewoon een omschrijving van een klasse (vb. Student) die gebruikt wordt om data van 1 record bij te houden en te transporteren tussen de verschillende lagen. Binnen deze klasse zitten ook validatieregels (vb. controle op max. lengte naam student).
Gewoon een object dus, maar zonder de methods ofzo?
quote:
Wat betreft stored procedures, die lijken zeker interessant. Aangezien ik nu zal werken met MSDE zal ik die wel kunnen gebruiken, dus daar zal ik proberen ook iets over te vinden.
Moet je zeker doen. MSDE is gewoon de Sql Server engine, dus kan je er op dezelfde manier als in Sql Server met SP's werken. De taal die gebruikt wordt om SP's mee te maken is Transact SQL (T-SQL). In de nabije toekomst zou het echter ook mogelijk zijn om in C# stored procedures te schrijven.

DevLog - FotoLog


  • pussher22
  • Registratie: april 2003
  • Laatst online: 11-06-2003
quote:
whoami schreef op 15 april 2003 @ 10:50:
[...]

Gewoon een object dus, maar zonder de methods ofzo?

[...]


Met de nodige getters en setters natuurlijk.

Wat betreft die SP's, zijn er artikels die je kan aanbevelen om dit snel onder de knie te krijgen?

pussher22 wijzigde deze reactie 15-04-2003 10:53 (3%)


  • whoami
  • Registratie: december 2000
  • Laatst online: 08:07
quote:
pussher22 schreef op 15 april 2003 @ 10:53:
Wat betreft die SP's, zijn er artikels die je kan aanbevelen om dit snel onder de knie te krijgen?


Stored Procedures schrijven is niet zo heel moeilijk.
Ik denk dat dit een goeie start is.

Ook dit artikel kan interessant zijn.

Verder kan je ook nog informatie vinden in de Books Online van Sql Server.

whoami wijzigde deze reactie 15-04-2003 11:01 (11%)

DevLog - FotoLog


  • pussher22
  • Registratie: april 2003
  • Laatst online: 11-06-2003
Ik zal die es bekijken, alvast bedankt!

  • EfBe
  • Registratie: januari 2000
  • Niet online
Voor het grootste bulkwerk van je stored procedures en de code om ze aan te roepen gebruik je een generator: bv de mijne ;) (LLBLGen http://www.sd.nl/software )

Genereert ook VB.NET code. Ik zou niet gaan voor dataset's tenzij je een single user applicatie wilt maken. Datasets zijn stateful, wat inhoudt dat in een multi-user omgeving je t.a.t. moet zorgen dat je de data die je wijzigt in het proces van user X doorgeeft aan de andere processen van de andere users. Dit is bv het geval in een webapplicatie. Verstandiger is het dan om te kiezen voor de state in de database, waardoor je bij het request van iedere user kijkt in de database wat de huidige state is en zodra je iets wijzigt, je dat terugschrijft in de database, en niet bewaart in memory. Zodoende kan een andere user dan meteen de wijzigingen zien, want die leest domweg weer uit de database. Datasets zijn gericht op het bewaren van data in memory, wat het lastig maakt dit te realiseren.

Lead developer of LLBLGen Pro, the productive O/R mapper for .NET
My .NET Blog | Twitter


  • whoami
  • Registratie: december 2000
  • Laatst online: 08:07
quote:
EfBe schreef op 15 april 2003 @ 11:54:
Genereert ook VB.NET code. Ik zou niet gaan voor dataset's tenzij je een single user applicatie wilt maken. Datasets zijn stateful, wat inhoudt dat in een multi-user omgeving je t.a.t. moet zorgen dat je de data die je wijzigt in het proces van user X doorgeeft aan de andere processen van de andere users. Dit is bv het geval in een webapplicatie. Verstandiger is het dan om te kiezen voor de state in de database, waardoor je bij het request van iedere user kijkt in de database wat de huidige state is en zodra je iets wijzigt, je dat terugschrijft in de database, en niet bewaart in memory. Zodoende kan een andere user dan meteen de wijzigingen zien, want die leest domweg weer uit de database. Datasets zijn gericht op het bewaren van data in memory, wat het lastig maakt dit te realiseren.
Je kan er toch voor zorgen dat alle wijzigingen in de DataSet weggeschreven worden naar de database? (via de Update Method).

DevLog - FotoLog


  • EfBe
  • Registratie: januari 2000
  • Niet online
quote:
whoami schreef op 15 April 2003 @ 12:00:
Je kan er toch voor zorgen dat alle wijzigingen in de DataSet weggeschreven worden naar de database? (via de Update Method).

Ja, maar je wilt bv 4 dingen wijzigen. Dan moet je die eerst wijzigen in je dataset. Dat lukt. Dan moet je die doorvoeren naar de database. Dat lukt bv niet (3e gaat mis). En dan? Je moet dan je dataset weer terugrollen, als dat al mogelijk is. Wat veel extra werk is en niets toevoegt. Een wijziging kan bv wel goed gaan in je datasaet want je hebt daar geen last van een of andere constraint, maar als je wijzigt in de database gaat het mis want een andere user heeft bv net een row toegevoegd en een unique constraint houdt je tegen om jouw changes door te voeren.

Er ontstaat dan een situatie die vermeden kan worden, daarom is een dataset eigenlijk alleen geschikt voor single user applicaties, want dan ben jij de enige op de database, en is de state in jouw user-process DE state van de app. Zodra dat verschilt, dus dat in andere user-processes de state anders is, moet je zoeken naar een common-state, en je komt dan al snel op OF een middlelayer waar iedere user verbinding mee maakt (bv een webservice die alles in core houdt) of de database (de aanbevolen situatie).

Lead developer of LLBLGen Pro, the productive O/R mapper for .NET
My .NET Blog | Twitter


  • whoami
  • Registratie: december 2000
  • Laatst online: 08:07
Hmmm... Je hebt daar inderdaad wel een punt.
Jij stelt dus voor om zowiezo gebruik te maken van eigen objecten in de business-logic laag?

DevLog - FotoLog


  • EfBe
  • Registratie: januari 2000
  • Niet online
quote:
whoami schreef op 15 April 2003 @ 13:07:
Hmmm... Je hebt daar inderdaad wel een punt.
Jij stelt dus voor om zowiezo gebruik te maken van eigen objecten in de business-logic laag?

Nee dat hoeft helemaal niet. Wat je nodig hebt zijn objects die het gemakkelijk maken entiteiten te modificeren/toe te voegen/te verwijderen in de central state repository, normaliter de database. Daarnaast is het noodzaak dat je objects hebt die de datalijsten ophalen die je nodig hebt voor je BL/gui code.

Het is niet voor niets dat LLBLGen juist de DAL creeert die het creeert :). 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.

De essentie echter blijft dat je t.a.t. moet beseffen in een multi-user omgeving dat de state in je code at runtime als 'zeer vluchtig' moet worden beschouwd, zodat je wanneer je dingen wijzigt, ze meteen doorvoert naar de database, en data ook betrekt uit de database ipv uit in core objects die je 'nog had bewaard van een vorige actie'.

MS noemt twee verschillende paradigmas: de dataset approach en de 'datareader' approach. De dataset approach is bekend, de datareader approach is eigenlijk wat LLBLGen genereert en eigenlijk de meest gebruikte methodiek om n-tier systemen te bouwen: set/modify code werkt direct op de tabellen in de database en je hebt daarnaast een scala aan 'retrieval' code die data uit de database trekt en in een structuur plaatst. (of dat met datareaders of met dataadapters + datatables gebeurt is niet belangrijk, het is belangrijk te beseffen dat deze data t.a.t. READONLY is, dus wijzigingen breng je er niet op aan).

Uit betrouwbare bron weet ik dat MS in vs.net 2004 doorgaat op de dataset methodiek met enkele aanvullingen, wat wel een teleurstelling is op zich. Ook is 'objectspaces' uit beeld verdwenen, het zal wel opduiken als een 'server' achtig systeem dat geld gaat kosten ben ik bang.

Lead developer of LLBLGen Pro, the productive O/R mapper for .NET
My .NET Blog | Twitter


  • Scare360
  • Registratie: juli 2001
  • Laatst online: 08:38
quote:
EfBe schreef op 15 april 2003 @ 13:32:
[...]

Uit betrouwbare bron weet ik dat MS in vs.net 2004 doorgaat op de dataset methodiek met enkele aanvullingen, wat wel een teleurstelling is op zich. Ook is 'objectspaces' uit beeld verdwenen, het zal wel opduiken als een 'server' achtig systeem dat geld gaat kosten ben ik bang.


Dit kan ik bevestigen, MS gaat op basis van datasets een persistence laag bouwen welke op meta data/xml berust. ObjectSpaces is uit de lucht gehaald vanwegen de nieuwe strategie... DataSets all the way. Waarschijnlijk inbedden in SQL Server.


Pusher22: Ik heb een DataMapper pattern geimplementeerd (zie Fowler), maar in veel gevallen volstaat een Table Module (Fowler) desnoods gebruik je voor complexe relaties typed DataSet's alhoewel je dan problemen met inheritance krijgt.

PSN (PS4): Scare360


  • whoami
  • Registratie: december 2000
  • Laatst online: 08:07
quote:
paulgielens schreef op 15 April 2003 @ 15:25:
[...]


Dit kan ik bevestigen, MS gaat op basis van datasets een persistence laag bouwen welke op meta data/xml berust. ObjectSpaces is uit de lucht gehaald vanwegen de nieuwe strategie... DataSets all the way. Waarschijnlijk inbedden in SQL Server.

Wat moet (of moest) ik me eigenlijk voorstellen bij ObjectSpaces ?

quote:
Pusher22: Ik heb een DataMapper pattern geimplementeerd (zie Fowler), maar in veel gevallen volstaat een Table Module (Fowler) desnoods gebruik je voor complexe relaties typed DataSet's alhoewel je dan problemen met inheritance krijgt.
* whoami is er ook wel in geinteresseerd........ :)

DevLog - FotoLog


  • Scare360
  • Registratie: juli 2001
  • Laatst online: 08:38
quote:
whoami schreef op 15 April 2003 @ 17:21:
[...]

Wat moet (of moest) ik me eigenlijk voorstellen bij ObjectSpaces ?

* whoami is er ook wel in geinteresseerd........ :)


ObjectSpaces was/is Microsoft’s initiatief voor een object/relationeel (OR) mapping framework. De basis bestaat uit meta data en xml om de daadwerkelijke mapping te realiseren. Het team bij Microsoft heeft blijkbaar ingezien dat DataSets indien die zoals EfBe al aangeeft een beetje versleuteld worden redelijk tot goed in te zetten voor persistence frameworks. Wat ik begrepen heb van Chris Hollander (MS medewerker) is dat je:
DataSet gaat gebruiken als transportmiddel over de layers.
Typed DataSet voor relaties, business relaties.
Custom Business Entities voor complexe business logica.

Ik heb voor mijn framework custom entities gemaakt, deze erven van een AbstractDomainEntity welke de structuur voor Lazy Loading bevat. Gebruik Identity Maps voor caching van entities, en Registry + Super Layer voor find functies en een centrale ingang naar m’n entity storage. DataMappers implementeren de vind functies. De DataMapper besteed het ophalen van relationele data uit aan de DataGateway, dit is een LLBLGen klasse.

Dit is dus nodig om een domein model te vullen en daar doorheen te kunnen traceren, zoals je bv een kortste pad zou bereken. Zodra ik trace resultaten heb, dus een pad heb weten te achterhalen geef ik de detail informatie weer door gewoon direct de DataGateway aan te spreken. Ik gebruik de custom entities dus alleen voor complexe logica.

Lees dit artikel maar eens

PSN (PS4): Scare360


  • EfBe
  • Registratie: januari 2000
  • Niet online
Maar, wat ik uit gesprekken met Thomas Tomiczek (developer EntityBroker) concludeer is dat MS de weg compleet kwijt is mbt persistence frameworks. Datasets zijn nu al een ramp om mee te werken, ZEKER typed datasets, want die zijn nauwelijks te maken zonder omslachtige handelingen. In theorie lijkt het allemaal aardig, maar zodra je ermee gaat werken wordt het een omslachtige brei. Dit komt omdat ze geen eenduidige poort hebben tot de data, je kan niet een object openen en daarmee je data bereiken met makkelijke handelingen, je moet een scala aan objects gebruiken en ook in de goede volgorde. Door op de dataset-weg verder te gaan los je de fundamentele flaws in het design niet op, je verzeilt alleen in de situatie dat je dat knoeiwerk gaat oplappen met meer knoeiwerk of erger: verbergt met een laagje vernis. (lees: in VS.NET een generatortje maken die wat werk voor je doet, maar dan ook alleen in bepaalde gevallen). Een dataset om data op te halen en daarmee typed te werken (dus dsMyDataset[iRowCounter].CustomerID ) lukt nog wel, maar data modificeren in een dataset, ookal is deze typed, weer niet, zeker niet als je met entiteiten bezig bent, dus in de situatie dat persistence frameworks die werken met louter 1:1 afbeeldingen van tabellen op classes WEL goed voldoen.

Ik snap ook totaal niet waarom MS uberhaupt de dataset bedacht heeft. In VS6 had je de verschrikkelijke dataadapter die dan gesleept kon worden op een asp page (!) en je daarmee leuk lijstjes kon maken. Nou dat gebruikte geen mens omdat dat voor geen meter performde en niet onderhoudbaar was, immers je had alle database code in je asp page zitten op ene verschrikkelijke manier. De dataset is daar een successor van, echter gebaseerd op hetzelfde domme idee. Verder heb je om echt productief te zijn met een dataset visual studio.net nodig, omdat je daar snel classes die werken met een dataset kunt 'designen', door een dataset en zn sidekicks dataadapter en een connection naar je form te slepen (of enterpriseservices derived (!) class) .

Al die jaren van n-tier development, Windows DNA en andere buzzwords ten spijt, MS heeft dat compleet genegeerd en heeft gekozen voor de meest domme oplossing die ze konden verzinnen: de dataset.

Om aan te geven HOE dom het in elkaar steekt: je kunt WEL de xml representatie verkrijgen van de data in een datatable (!) object in een dataset, maar je kunt de xml representatie van de data in een datatable weer NIET verkrijgen, DIRECT uit die datatable. m.a.w: je MOET datasets gebruiken wil je die xml hebben, en dat terwijl de data toch echt in de datatables zit en niet in de dataset zelf.

Paul: dat artikel geeft overigens aan waar MS werkelijk naar toe wil: wanneer je werkelijk iets wilt met business logic, koop dan onze 'biztalk' server en andere leuke producten.

EfBe wijzigde deze reactie 16-04-2003 10:06 (6%)

Lead developer of LLBLGen Pro, the productive O/R mapper for .NET
My .NET Blog | Twitter


  • whoami
  • Registratie: december 2000
  • Laatst online: 08:07
EfBe, was jij tot voor kort geen DataSet advocate (als ik het zo mag noemen?). :P

Ik heb zelf nog niet genoeg met DataSets gewerkt om er diep op in te kunnen gaan, maar wat ik wel weet is dat die DataSets volgens consultants van bv InfoSupport wel 'the way to go' zijn.

DevLog - FotoLog


  • EfBe
  • Registratie: januari 2000
  • Niet online
quote:
whoami schreef op 16 april 2003 @ 18:00:
EfBe, was jij tot voor kort geen DataSet advocate (als ik het zo mag noemen?). :P

NO WAY ! :)
DataTables zijn leuk, datasets zijn pure overkill, en nog net niet zo onnozel als datareaders, maar ze schurken wel tegen elkaar aan om de eerste plek in de top 10 aller tijden der onbenullige technologieen. ;)

quote:
Ik heb zelf nog niet genoeg met DataSets gewerkt om er diep op in te kunnen gaan, maar wat ik wel weet is dat die DataSets volgens consultants van bv InfoSupport wel 'the way to go' zijn.
hmm. Datasets zijn de objects die veelal worden onderwezen in cursussen, vandaar. En als een consultant roept 'that's the way to go' over dataset zou ik toch een ander inhuren, er zijn er genoeg tegenwoordig ;)

Lead developer of LLBLGen Pro, the productive O/R mapper for .NET
My .NET Blog | Twitter


  • paullooijmans
  • Registratie: februari 2003
  • Laatst online: 08-02-2007
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....

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.

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.

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).

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.

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! 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.

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 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?

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!

EfBe is geweldig !


  • EfBe
  • Registratie: januari 2000
  • Niet online
quote:
paullooijmans 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:

quote:
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.

quote:
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?

quote:
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.

quote:
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.

quote:
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.
quote:
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.

quote:
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.

quote:
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.

quote:
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.

EfBe wijzigde deze reactie 17-04-2003 11:18 (9%)
Reden: typos/flames;)

Lead developer of LLBLGen Pro, the productive O/R mapper for .NET
My .NET Blog | Twitter


  • tijn
  • Registratie: februari 2000
  • Laatst online: 13-11 23:56
quote:
EfBe schreef op 17 April 2003 @ 11:06:
[...]

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.

Als ik het goed begrepen heb is je DataSet rant gebaseerd op de combinatie DataSet - DataAdapter. In zekere zin kan ik wel meegaan in je argumentatie, alleen mag je niet de schuld geven aan die arme DataSet alleen ;). Ik denk dat je bezwaren vooral voort komen door de methode waarmee de DataAdapter data toevoegt/wijzigt/verwijdert of niet?
Als je een Dataset even los hiervan bekijkt is het zo'n gek ding nog niet en vooral in situaties waar helemaal geen database gebruikt wordt (PDA's enzo) kun je er goed mee werken.

Cuyahoga .NET website framework


  • EfBe
  • Registratie: januari 2000
  • Niet online
quote:
tijn schreef op 17 April 2003 @ 11:44:
Als ik het goed begrepen heb is je DataSet rant gebaseerd op de combinatie DataSet - DataAdapter. In zekere zin kan ik wel meegaan in je argumentatie, alleen mag je niet de schuld geven aan die arme DataSet alleen ;). Ik denk dat je bezwaren vooral voort komen door de methode waarmee de DataAdapter data toevoegt/wijzigt/verwijdert of niet?

De Dataadapter is noodzakelijk voor het bewerkstelligen van wat je wilt doen met de dataset (of dat goed is laat ik maar even in het midden ;)). Mijn argument is dat je 2 keer de wijzigingen moet doorvoeren, nl zowel IN de dataset, als IN de database. Hoe dat gebeurt doet niet terzake, de dataset wijzigt zelf nl. niet automatisch de gegevens in de database, het is immers een disconnected set data. De dataadapter is een middel om die wijzigingen door te voeren vanuit de dataset, die kan er niets aan doen, het gaat om de functionaliteit die de dataset biedt en of je daar op zit te wachten. Omdat MS qua tools voor de alternatieven van de dataset approach geen tools levert, zit je al snel op het spoor van de dataset en dat is glad ijs als je niet doordrongen bent van de gevaren ervan.

quote:
Als je een Dataset even los hiervan bekijkt is het zo'n gek ding nog niet en vooral in situaties waar helemaal geen database gebruikt wordt (PDA's enzo) kun je er goed mee werken.
Zou een lightweight object als een dataview of datatable dan niet voldoen? Ik denk het wel.

Lead developer of LLBLGen Pro, the productive O/R mapper for .NET
My .NET Blog | Twitter


  • tijn
  • Registratie: februari 2000
  • Laatst online: 13-11 23:56
quote:
EfBe schreef op 17 april 2003 @ 11:52:
[...]
Zou een lightweight object als een dataview of datatable dan niet voldoen? Ik denk het wel.
Mja, als die nou ook ReadXml en GetXml methods zouden hebben. Daarnaast kun je met relationships nog wel enige vorm van integriteit behouden waar dat met losse datatables lastiger is (naja, je moet het zelf schrijven, maar ik ben lui :)).

Cuyahoga .NET website framework


  • whoami
  • Registratie: december 2000
  • Laatst online: 08:07
quote:
EfBe schreef op 17 April 2003 @ 11:52:
[...]

De Dataadapter is noodzakelijk voor het bewerkstelligen van wat je wilt doen met de dataset (of dat goed is laat ik maar even in het midden ;)). Mijn argument is dat je 2 keer de wijzigingen moet doorvoeren, nl zowel IN de dataset, als IN de database. Hoe dat gebeurt doet niet terzake, de dataset wijzigt zelf nl. niet automatisch de gegevens in de database, het is immers een disconnected set data. De dataadapter is een middel om die wijzigingen door te voeren vanuit de dataset, die kan er niets aan doen, het gaat om de functionaliteit die de dataset biedt en of je daar op zit te wachten. Omdat MS qua tools voor de alternatieven van de dataset approach geen tools levert, zit je al snel op het spoor van de dataset en dat is glad ijs als je niet doordrongen bent van de gevaren ervan.


Op die manier heb je een scheiding tussen de data en hoe je de data in de DB moet gaan opslaan, ophalen. Dat vind ik geen slechte manier.
Als je met custom objects werkt, moet je de data die je wijzigt in de objecten ook nog naar de DB gaan persisten.

DevLog - FotoLog


  • EfBe
  • Registratie: januari 2000
  • Niet online
quote:
whoami schreef op 17 april 2003 @ 13:28:
Op die manier heb je een scheiding tussen de data en hoe je de data in de DB moet gaan opslaan, ophalen. Dat vind ik geen slechte manier.

Daar is ook niets mis mee, je verliest alleen uit het oog waar nu de werkelijke application state zich bevindt, of althans, waar je in theorie moet kijken om een beslissing te nemen (bv om in mijn voorbeeld hierboven te spreken: dat U2 wel of niet die wijziging moet gaan doen in zn dataset). In een multi-user applicatie is het t.a.t. essentieel dat je ZEKER kunt zijn van de validiteit van je data die je LEEST, waar je als BL dus beslissingen op baseert. Het is dan van het grootste belang dat je t.a.t. in je centrale applicatie state je data accuraat bijhoudt en bij wijzigingen daarin in een userproces die ook meteen doorvoert op de database, en in alle gevallen leest vanuit de database ipv dat je uit cached data leest. Dit KAN trager zijn, maar je weet 1 ding wel zeker: je data is correct, je applicatie werkt zoals gedesigned en je hebt er geen omkijken naar. In Enterprise Applications is dat essentieel, veelal omdat ze dermate complex zijn dat 'even debuggen' er niet inzit.

quote:
Als je met custom objects werkt, moet je de data die je wijzigt in de objecten ook nog naar de DB gaan persisten.

Dat klopt. Als je bv collections van 'customers' in memory houdt en daar eerst een setje 'customer' objects aantoevoegt, dan 'save' aanroept van die objects, is dat uiteraard exact eender aan een dataset en daar wat rijen aan toevoegen, de rij in de dataset heeft alleen een andere gedaante, maar de problemen die ermee spelen zijn precies dezelfde.

Kijk, iedere enterprise application developer moet maar doen wat hij/zij denkt dat goed is. Het model dat ik aanhang is bewijsbaar correct in alle gevallen. Je kunt geen situatie opstellen, bv een voorbeeld zoals ik hierboven heb aangegeven, waarbij je in de problemen komt, zodanig dat je eerder 'goed afgeronde' code als 'toch niet helemaal geslaagd' moet afronden. Ik begrijp dat veel mensen graag willen geloven dat wat Microsoft zegt waar is en de beste manier om dingen te doen. Met de dataset en het concept daarachter is dit m.i. niet het geval, en je kunt dat ook aantonen. Mijn voorbeeld hierboven is eventueel nog wel omver te programmeren, maar bij extremere gevallen, waarbij data in core wordt gehouden, wordt uitgelezen voor BL beslissingen en waarbij de data NIET pal voor die leesactie ge-refetched wordt uit de database (met alle gevolgen van dien) wordt dat al lastiger. En als iets lastiger wordt en er is een simpel alternatief, dan is de keuze, zeker in het kader van complexe applicaties als enterprise applicaties, vrij voor de handliggend lijkt me :)

(Microsoft geeft overigens NERGENS aan wat het gevaar is van het in core houden van resultsets in Datasets in multi-user applicaties zoals webapplicaties. Ervaren enterprise developers weten wel dat ze daar op moeten letten, het gros echter weet dit niet, leest er niet over en leest wel over de dataset, ziet de handige tools en gaat daar mee bezig. Met alle gevolgen van dien)

EfBe wijzigde deze reactie 17-04-2003 14:19 (8%)

Lead developer of LLBLGen Pro, the productive O/R mapper for .NET
My .NET Blog | Twitter


  • Scare360
  • Registratie: juli 2001
  • Laatst online: 08:38
Verdomd strakke post EfBe, ff de meningsverschillen daargelaten. Dit komt overeen met mijn conclusie getrokken uit een onderzoek naar enterprise architectuur. .NET komt te kort op het gebied van persistence, en ook niet zo'n beetje ook. MS lost het state probleem in de DataSet op door gemodificeerde rows aan te duiden. Zie TaskVision, echt te triest voor woorden. Maar... MS weet als geen ander de DataSet en de typed DataSet op de voorgrond te gooien wat nog wel eens voor verwarring wil zorgen. Denk dat we elkaar daar niet op af moeten rekenen.

Ik wil gewoon custom business entity classes (sets) die transparant persistable zijn, maar daar houdt het bij MS "voorlopig" op.

paullooijmans: Je hebt nog steeds niet op mijn vraag (e-mail) gereageerd? Ik ben op de parser blijven hangen zeg maar.

Op dotnetweblogs wordt de discussie ook warm gehouden... hier heb ik wat persoonlijke bevindingen gedropt. Ik denk dat deze toollist de moeite waard is om te bekijken. Als iemand de oplossing heeft voor dit vraagstuk... dan ben je waarschijnlijk de eerste ;)

PSN (PS4): Scare360


  • maikel
  • Registratie: januari 2001
  • Laatst online: 21-11 14:47
@EfBe:
In het geval van webapplicaties moet je sowieso de data opnieuw ophalen / de objecten opnieuw vullen na een postback. Zodoende werk je (bijna) altijd met de nieuwste gegevens.

Hoe sla jij je gegevens dan precies op?
Bij webapplicaties blijf je toch altijd met het probleem zitten dat de gegevens die de user gezien heeft anders kunnen zijn dan de gegevens in de database.

Tevens kun je bij gebruik van datasets meteen zien welke gegevens niet meer overeenkomen met de database en daar een mooie melding van maken.
In het laatste .Net Magazine staat daar een mooi voorbeeld van.

  • EfBe
  • Registratie: januari 2000
  • Niet online
quote:
maikel schreef op 17 April 2003 @ 14:38:
@EfBe:
In het geval van webapplicaties moet je sowieso de data opnieuw ophalen / de objecten opnieuw vullen na een postback. Zodoende werk je (bijna) altijd met de nieuwste gegevens.

Dat is voor een aantal mensen logisch, voor veel ook niet, die denderen bij de page start een dataset in de session/viewstate en gaan daar bij de postback vrolijk mee verder.

quote:

Hoe sla jij je gegevens dan precies op?
Bij webapplicaties blijf je toch altijd met het probleem zitten dat de gegevens die de user gezien heeft anders kunnen zijn dan de gegevens in de database.

Ja, je hebt altijd dat je op tijdstip T gegevens laadt en dat die dus op T+1 gewijzigd kunnen worden door een andere user. Indien je dat niet wilt, zul je daar maatregelen tegen moeten nemen (functional locking bv, of keiharde locks in de database *shiver*, er zijn legio mogelijkheden). Het gaat echter om het punt dat je op tijdstip T er vanuit kunt gaan dat op dat moment de data correct is. Als je logica daarop gebaseerd is (en 99% van de webapplicaties werkt zo) moet je dus wel daar ook vanuit kunnen gaan. Vandaar dat je het enige dat je hebt, de centrale applicatie state, zo snel mogelijk moet updaten zodra je wijzigingen daarvoor hebt, bij voorkeur direct, dus object creeeren, properties zetten en save/update aanroepen en die method voert dan direct een sp uit/query uit. Daarna object weggooien.

quote:

Tevens kun je bij gebruik van datasets meteen zien welke gegevens niet meer overeenkomen met de database en daar een mooie melding van maken.
In het laatste .Net Magazine staat daar een mooi voorbeeld van.
Meteen zien? :) Het ding is disconnected, waardoor je naar de database toe moet, je table opnieuw moet fetchen en daarmee verder moet werken. Ik heb het .net magazine (de laatste) niet meer, ik kan dat voorbeeld niet meer inzien helaas.

Lead developer of LLBLGen Pro, the productive O/R mapper for .NET
My .NET Blog | Twitter


  • EfBe
  • Registratie: januari 2000
  • Niet online
quote:
paulgielens schreef op 17 April 2003 @ 14:28:
Verdomd strakke post EfBe, ff de meningsverschillen daargelaten. Dit komt overeen met mijn conclusie getrokken uit een onderzoek naar enterprise architectuur. .NET komt te kort op het gebied van persistence, en ook niet zo'n beetje ook. MS lost het state probleem in de DataSet op door gemodificeerde rows aan te duiden. Zie TaskVision, echt te triest voor woorden. Maar... MS weet als geen ander de DataSet en de typed DataSet op de voorgrond te gooien wat nog wel eens voor verwarring wil zorgen. Denk dat we elkaar daar niet op af moeten rekenen.

Precies, MS positioneert de Dataset in zn huidige staat verkeerd, geeft de valkuilen niet aan en duwt je wel die richting op, want anders sta je tegen een inmense muur van werk aan te kijken. (als je geen generator hebt).

quote:
Ik wil gewoon custom business entity classes (sets) die transparant persistable zijn, maar daar houdt het bij MS "voorlopig" op.
Transparant, als in: jij roept save aan en hij update zichzelf naar de database, en houdt zelf bij of hij out of date is of niet (dus refetcht zichzelf wanneer dat nodig is?)
quote:
Op dotnetweblogs wordt de discussie ook warm gehouden...

"OlyMars

Let me put it this way. If the instructions for using a condom were as complicated as the ones for using OlyMars, AIDS would have killed us all by now. "
LOL :D

quote:
Als iemand de oplossing heeft voor dit vraagstuk... dan ben je waarschijnlijk de eerste ;)
Ik hoop het antwoord te geven binnen een aantal maanden, maar zoals met alles: het is altijd een compromis, en elk vraagstuk kan, wanneer je prioreiten anders stelt (dus correctheid valt wel wat mee, maar performance is essentieel) een andere oplossing opleveren bij verschillende mensen. :)

Lead developer of LLBLGen Pro, the productive O/R mapper for .NET
My .NET Blog | Twitter


  • whoami
  • Registratie: december 2000
  • Laatst online: 08:07
Wat gebruik jij dan EfBe in .NET om business entiteiten voor te stellen?

DevLog - FotoLog


  • EfBe
  • Registratie: januari 2000
  • Niet online
quote:
whoami schreef op 17 April 2003 @ 16:05:
Wat gebruik jij dan EfBe in .NET om business entiteiten voor te stellen?

op logica gebaseerde classes. Ik gebruik geen 'Customer' objects om bv 'customer' related dingen te regelen. Ik maak classes gebaseerd op welke functionaliteit gebouwd moet worden, daar knoop ik enerzijds de DAL aan voor I/O naar de database en anderzijds leg ik er een laag op voor de GUI.

Het is zo makkelijk om na een uitgebreide functionele beschrijving de code te designen, want je focust op functionaliteit en modelleert je code daaraan.

Zo bouw ik dan bv een SecurityManager class om users te beheren, geen User class, een typed users collectie en daarin securitylogica. Dit is niet het meest efficiente en niet het meest 'OO', maar een functionele beschrijving is er wel makkelijk op af te beelden en de code is dan ook straightforward en simpel (saai bijna ;)). Omdat ikzelf procedureel geschoold ben, intereseert me een 'meest pure OO' oplossing niet zo, er zijn meer wegen die naar rome leiden, maar OO kan je wel voordelen bieden en dat vereist kennis van bv standaard patterns, daar schort het bij mij nog wel aan, heb ook net het GoF boek besteld.

Een andere reden waarom ik de functionele benadering heb gekozen is puur een praktische: het vereist veel minder code. Alleen met een generator voor de objects die entiteiten voorstellen is het voordelig om op die manier te werken. Zonder generator type je je het schompes aan al die classes, waarbij je je moet afvragen of de voordelen (makkelijker programmeren van BL door derden die niet bekend zijn met de database en dus niet een dataview/table kunnen uitlezen) opwegen tegen de berg extra werk die je moet verzetten.

Als ik een generator zou hebben die die classes voor me zou genereren zou ik ze wel gebruiken in veel gevallen, maar toch zou ik denk ik dan in veel gevallen een functionele benadering kiezen boven een puur OO model dat dan 'gemapped' moet worden op de functionaliteit die je wilt gaan bouwen. Een combinatie is imho dan ook de te prefereren situatie, dus EN entiteitenobjects (1:1 afbeeldingen van database tables op classes met bare logic om ze te getten/updaten etc, typed collections van die objects met bindable interfaces) EN lijstlogica die in feite niets meer is dan een typed datatable, zodat je EN functioneel je code kunt opstellen ipv te verdrinken in een pure OO tree, EN je in andere gevallen puur OO bezig kunt zijn. Dit is mn doel voor LLBLGen v2.

Lead developer of LLBLGen Pro, the productive O/R mapper for .NET
My .NET Blog | Twitter


  • whoami
  • Registratie: december 2000
  • Laatst online: 08:07
quote:
EfBe schreef op 17 april 2003 @ 16:23:
[...]

op logica gebaseerde classes. Ik gebruik geen 'Customer' objects om bv 'customer' related dingen te regelen. Ik maak classes gebaseerd op welke functionaliteit gebouwd moet worden, daar knoop ik enerzijds de DAL aan voor I/O naar de database en anderzijds leg ik er een laag op voor de GUI.

Jij gaat dus bv. geen Customer class hebben die bv. functionaliteit voor één klant en zijn orders op zich neemt?
Hmmm.... nouja. Ik wel. :+

quote:
heb ook net het GoF boek besteld.

Dat is een goed boek. Ik heb het ook enkele maanden maar ik heb nog altijd niet alle patterns bekeken/bestudeerd. (Zoveel zijn er echter niet, ik denk een stuk of 24 dacht ik). Echter, niet alle patterns zijn even interessant (Hoe kan het ook anders. :P)
Al met al zeker een aanrader dat boek.

DevLog - FotoLog


  • Scare360
  • Registratie: juli 2001
  • Laatst online: 08:38
quote:
whoami schreef op 17 april 2003 @ 16:49:
Jij gaat dus bv. geen Customer class hebben die bv. functionaliteit voor één klant en zijn orders op zich neemt?
Hmmm.... nouja. Ik wel. :+


Let op: OO is in veel gevallen overkill, zolang je relatief simpele business relaties hebt en niet zoals mij (track & trace verhaal) complexe business logica, dus krachtige oplossingen om object trees af te fietsen heb je ruim voldoende aan het verhaaltje wat EfBe geeft. Probleem is dat bij onderhoud of bijbouwen van functionaliteit, je afstevent op hacky oplossingen. Zeker als "andere" mensen jouw werk oppikken en je systeem architectuur en daarmee het detail ontwerp niet helemaal bevatten.

Ik ben van 100% OO naar de middenweg gegaan, die oude rotten in de procedurele wereld hebben ook nog wel eens goede oplossingen en vaak straight to the point. Voor een recht to recht aan business oplossing volstaan die meestal wel. Of die nou superieur zijn qua ontwerp is nog tot daar aan toe (ik denk het niet).

PSN (PS4): Scare360


  • EfBe
  • Registratie: januari 2000
  • Niet online
quote:
whoami schreef op 17 april 2003 @ 16:49:
Jij gaat dus bv. geen Customer class hebben die bv. functionaliteit voor één klant en zijn orders op zich neemt?
Hmmm.... nouja. Ik wel. :+

Heh :) Ik bouw niet op voorhand voor elke tabel een class bedoelde ik. Als ik een CustomerManager nodig heb qua functionaliteit zal ik die zeker bouwen, maar of dat een entiteitclass is... denk het niet. Dat bedoelde ik een beetje :)

quote:

(GoF)
Al met al zeker een aanrader dat boek.
Ja die indruk kreeg ik ook, het is wel uit 1995, maar de patterns zijn geloof ik dermate universeel dat je ze overal kunt toepassen. Maar we drijven af :)

Lead developer of LLBLGen Pro, the productive O/R mapper for .NET
My .NET Blog | Twitter


  • paullooijmans
  • Registratie: februari 2003
  • Laatst online: 08-02-2007
quote:

... ik heb de afgelopen 4 maanden wel full time gespendeerd aan research op dit gebied naast het onderzoek van 3 maanden vorig jaar...

...Ik kan pagina's vol typen met argumenten voor mijn stelling...


Ik heb je posts nogmaals doorgelezen en kan enkel tot de conclusie komen dat je slechts 1 fundamenteel bezwaar hebt geuit tegen het gebruik van DataSets. Dit bezwaar komt er op neer dat de DataSet onvoldoende rekening houdt met concurrencyproblemen. In simpel nederlands: de data kan 'bederven' in de periode tussen het ophalen (dataAdapter.Fill) en weer wegschrijven (dataAdapter.Update) van de data.

Laat ik voorop stellen dat ik het probleem van concurrency onderken. Echter, ik ben het fundamenteel oneens met je dat de unieke eigenschappen van de DataSet op een bijzondere wijze bijdragen aan dit probleem en verder vind ik dat je nergens in de discussie hebt laten zien dat de door jouw gekozen oplossing het genoemde probleem oplost.

Als ik jouw oplossing mag samenvatten komt deze erop neer dat je "de centrale applicatie state zo snel mogelijk moet updaten zodra je wijzigingen daarvoor hebt, bij voorkeur direct". Laten we het voorbeeld nemen van 2 gebruikers die tegelijkertijd dezelfde data ophalen: A verandert een waarde en drukt op 'opslaan'. Ik neem toch niet aan dat je dan (zelfs wanneer dit technisch mogelijk zou zijn) bij gebruiker B de nieuw waarde OVER de door hem zojuist ingevulde waarde gaat heenzetten? Zo niet, dan heb je zowiezo een concurrency probleem, ongeacht welke oplossing je gebruikt (DataSet, DataReader, ObjectSpaces, LLBLGen etc. etc. etc.). Natuurlijk is het wel zo dat je de concurrency problemen VERMINDERT door de applicatie state zo vaak mogelijk op te halen, maar dat vind ik gezien het gewicht dat jij blijkbaar bij dit soort problemen legt een onvoldoende oplossing. Het probleem wordt namelijk niet veroorzaakt door de gekozen Data Access strategie, het probleem wordt veroorzaakt door het feit dat bepaalde data al verouderd kan zijn in de nanoseconde nadat je deze opgehaald hebt. Sterker nog, sommige databases laten het zelfs toe dat er tegelijkertijd gelezen en geschreven kan worden naar een rij (bijv. Oracle)!

De enige juiste oplossing voor concurrency problemen is dan ook om deze concurrency problemen tijdens het schrijven te kunnen signaleren, de gebruiker hiervan op de hoogte te stellen en deze de keuze geven wat te doen: de gegevens overschrijven of laten staan.

De DataSet maakt gebruik van optimistic concurrency bij het updaten en het is mogelijk met transacties te werken zodat je de application state weer terug kunt brengen naar hoe hij voor de updates was.

Aangezien je in de door jouw genoemde 'oplossing' nog steeds mogelijke concurrencyproblemen moet afvangen (ook al komen ze misschien minder voor, dat is geen excuus om ze niet af te vangen) zie ik niet hoe jouw oplossing fundamenteel beter is dan de DataSet methode.

Voeg daaraan toe dat je nergens kennis geeft van de mogelijke voordelen die DataSets bieden: performance-wise mbt bijv het niet ontbreken van roundtrips voor een groot aantal ingewikkelde operaties, qua functionaliteit op het gebied van de serialisering ervan of het feit dat het eenvoudig mogelijk is data uit een groot aantal verschillende datasources te combineren en te transformeren.

Al met al blijf ik van mening dat de DataSet wel degelijk een nuttige basis kan bieden voor een breed scala aan interessante applicaties. Maar goed, al met al is dat niet eens de rede dat ik (weer) zoveel tijd besteed aan deze post, ik ben eigenlijk niet eens een grote fan van de DataSet, maar gelukkig ben ik wel in staat met enige nuance te spreken over de verschillende technologieen.

Mijn ervaring is dat meer ervaring op welk vakgebied dan ook leidt tot meer nuance. Zaken zijn niet zwart/wit, goed/fout of ja/nee. Dat is dan ook juist de rede dat ik me zo stoorde aan de volstrekt ongenuanceerde posts van EfBe. Los van de in mijn ogen domweg onbeschofte en onnodig belerende taal die de man nu en in het verleden richting mij heeft geuit vind ik het nog steeds buitengewoon arrogant om zaken zo ongenuanceerd neer te zetten als hij heeft gedaan in deze thread. Vanmiddag viel mij plots z'n signature op: 'Fowler is een prutser'. Hoewel de referenties aan Fowler in dit forum mij zo onderhand ook gaan vervelen vind ik dit toch wel weer erg typisch.....

EfBe is geweldig !


  • EfBe
  • Registratie: januari 2000
  • Niet online
quote:
paullooijmans schreef op 18 April 2003 @ 02:07:
Ik heb je posts nogmaals doorgelezen en kan enkel tot de conclusie komen dat je slechts 1 fundamenteel bezwaar hebt geuit tegen het gebruik van DataSets. Dit bezwaar komt er op neer dat de DataSet onvoldoende rekening houdt met concurrencyproblemen. In simpel nederlands: de data kan 'bederven' in de periode tussen het ophalen (dataAdapter.Fill) en weer wegschrijven (dataAdapter.Update) van de data.

Het heeft geen ene reet met concurrency te maken. Concurrency is het concept dat je hanteert wanneer 2 of meer users tegelijk DEZELFDE data aan het modificeren zijn (zelfde set records) en daarna deze wijzigingen willen wegschrijven in de database en je moet beslissen welke wijzigingen behouden blijven (de 1e die worden weggeschreven, de laatste etc) en welke niet.

DIT probleem is iets heel anders, het gaat nl. over versnippering van applications state en ik heb met opzet een voorbeeld genomen waar geen concurrency probleem in zit, nl. beide users werken wel op dezelfde table maar op verschillende rows.

Concurrency gerelateerde problemen kun je t.a.t. oplossen op functioneel gebied, daar staat de dataset buiten. De dataset heeft overigens een optimistic concurrency beleid en als je daar achter staat dan is het een prima ding, maar het feit blijft dat application state versnippert over meerdere user processes en die moet je eigenhandig weer in sync krijgen.

quote:
Laat ik voorop stellen dat ik het probleem van concurrency onderken. Echter, ik ben het fundamenteel oneens met je dat de unieke eigenschappen van de DataSet op een bijzondere wijze bijdragen aan dit probleem en verder vind ik dat je nergens in de discussie hebt laten zien dat de door jouw gekozen oplossing het genoemde probleem oplost.

Je onderkent helemaal niks, je snapt niet waarover IK het had en wat onder concurrency wordt verstaan.

JIJ zegt nu dat in mijn ellenlange posting geen oplossing staat voor dit probleem. Dat staat er wel. Lees hem nog maar een keer door.

quote:
Als ik jouw oplossing mag samenvatten komt deze erop neer dat je "de centrale applicatie state zo snel mogelijk moet updaten zodra je wijzigingen daarvoor hebt, bij voorkeur direct".

Wanneer de 'application state' wijzigt in een user process moet je die wijzigingen zo snel mogelijk doorvoeren naar de feitelijke application state. Krijg je in logiga achter een form door dat de user iets heeft gewijzigd en dat dat een applicationstate wijziging is, dan moet je die wijzigingen niet eerst lokaal doorvoeren en dan ooit eens in de database, maar meteen in de database, of andere central repository waar je de application state in bewaart.

quote:
Laten we het voorbeeld nemen van 2 gebruikers die tegelijkertijd dezelfde data ophalen: A verandert een waarde en drukt op 'opslaan'. Ik neem toch niet aan dat je dan (zelfs wanneer dit technisch mogelijk zou zijn) bij gebruiker B de nieuw waarde OVER de door hem zojuist ingevulde waarde gaat heenzetten?

Dit is een totaal ander probleem. Wat jij aanhaalt is concurrency en wat ik aanhaalde was het probleem dat je in userproces A de application state wijzigt en in userproces B die wijziging moet gebruiken maar dat niet kan omdat je alleen maar kunt lezen uit de database en niet uit de in-memory data van userproces A.

Concurrency kun je op verschillende manieren oplossen: low level in de database (MVCC zoals in oracle en postgresql) of locking/lockhints zoals in de meeste RDBMS'en, hogerop door optimistic locking (eerst kijken of de huidige waarden die je wilt overschrijven gelijk zijn aan de waarden die je initieel hebt veranderd, wordt gebruikt door data-adapter-dataset) of functioneel, dus persoon A wil functionaliteit F gaan gebruiken die 2 records wijzigt, persoon B kan dat dan niet doen, want A is er al mee bezig. Een versie hiervan wordt bv door office gebruikt bij documenten (open maar eens 2 keer hetzelfde document in word. De 2e zal read-only zijn). En zo zijn er nog meer schema's bedacht. Heeft totaal NIETS maar dan ook NIETS met wat ik bedoelde te maken.

Ik dender overigens de data van B vrolijk over A heen, het is nl. lood om oud ijzer. Als de data van A behouden moet blijven bouw ik een locking mechanisme in op functioneel niveau.

quote:
Zo niet, dan heb je zowiezo een concurrency probleem, ongeacht welke oplossing je gebruikt (DataSet, DataReader, ObjectSpaces, LLBLGen etc. etc. etc.). Natuurlijk is het wel zo dat je de concurrency problemen VERMINDERT door de applicatie state zo vaak mogelijk op te halen, maar dat vind ik gezien het gewicht dat jij blijkbaar bij dit soort problemen legt een onvoldoende oplossing. Het probleem wordt namelijk niet veroorzaakt door de gekozen Data Access strategie, het probleem wordt veroorzaakt door het feit dat bepaalde data al verouderd kan zijn in de nanoseconde nadat je deze opgehaald hebt. Sterker nog, sommige databases laten het zelfs toe dat er tegelijkertijd gelezen en geschreven kan worden naar een rij (bijv. Oracle)!

Concurrency problemen worden niet minder als je de data blijft ophalen. Je hebt nu de discussie verplaatst van stateful vs stateless naar concurrency problemen. Je moet beter lezen. Ik had het over of je data uit de centrale application state (database) haalt voor een zeker BL proces of dat je kijkt in de al aanwezige data in je userproces voor dat zekere BL proces. Dataset propageert het laatste, terwijl dat aantoonbaar incorrect is. Heeft geen reet met concurrency te maken.

quote:
De enige juiste oplossing voor concurrency problemen is dan ook om deze concurrency problemen tijdens het schrijven te kunnen signaleren, de gebruiker hiervan op de hoogte te stellen en deze de keuze geven wat te doen: de gegevens overschrijven of laten staan.

Dat is een flutoplossing, want je laat de user wel eerst werk doen dat hij nooit kan opslaan. Beter is om de user uberhaupt de wijzigingen niet te laten doen, immers hij zal ze nooit kunnen opslaan bij bv optimistic locking als hij wat traag is. Concurrency is een organisatorisch probleem trouwens: welk proces/user mag wat doen en waarom. 2 developers die dezelfde sourcefile lopen te editen vragen ook om problemen.

quote:
De DataSet maakt gebruik van optimistic concurrency bij het updaten en het is mogelijk met transacties te werken zodat je de application state weer terug kunt brengen naar hoe hij voor de updates was.

Goh. Je kunt de dataset ook weer terugbrengen naar de toestand voordat je de wijzigingen IN de dataset doorvoerde? Neen.

quote:
Aangezien je in de door jouw genoemde 'oplossing' nog steeds mogelijke concurrencyproblemen moet afvangen (ook al komen ze misschien minder voor, dat is geen excuus om ze niet af te vangen) zie ik niet hoe jouw oplossing fundamenteel beter is dan de DataSet methode.

Mijn punt had NIETS te maken met concurrency! Het lost dus ook geen concurrency op! Het oplossen van concurrency doe je niet door het gebruik van de dataset! Zoek eens op concurrency control mechanisms bij google. Je vindt dan aardig wat mechanismen die zijn onderzocht op universiteiten. Allemaal verschillend, en allemaal lossen ze het wel op maar tegen prijs.

Echter heeft dit NIETS te maken met stateful vs stateless wat de eigenlijke discussie was.

quote:
Voeg daaraan toe dat je nergens kennis geeft van de mogelijke voordelen die DataSets bieden: performance-wise mbt bijv het niet ontbreken van roundtrips voor een groot aantal ingewikkelde operaties, qua functionaliteit op het gebied van de serialisering ervan of het feit dat het eenvoudig mogelijk is data uit een groot aantal verschillende datasources te combineren en te transformeren.

Oh, dus wanneer ik datasets ga gebruiken draait mijn systeem qua performance beter? Ik moet 2(!) keer mijn wijzigingen doorvoeren en als de 2e keer mislukt (in de database) dan moet ik de 1e handmatig terugrollen. Verder is performance ook weer iets dat er bij gesleept wordt door jou, maar je hebt geen keuze: bij de aanvang van Business process B moet je het proces voorzien van de MEEST ACCURATE data. Die haal jij waar op? Ik iig uit de centrale application state: de database, en weet je waarom? Ik WEET dat op DAT MOMENT die state klopt.

Wil ik meer performance door die leesactie niet te doen, maar bv data te cachen? Prima, maar wel tegen de prijs dat je data wellicht niet correct is. Er is geen andere manier: je zult moeten verifieren dat de data die je in memory hebt correct is, en dat kun je alleen doen aan de hand van de data uit de centrale application state: de database. M.a.w.: je moet lezen uit de database, en DUS ben je die leesactie kwijt.

Ik begrijp je 'argument' over serializering niet echt, misschien moet je eens op cursus en wat termen leren. Verder als ik vele datasources wil combineren dan doe ik dat IN de dal, de BL werkt t.a.t. met 'data' in een vorm die het beste voor de BL te hanteren is, waar die vandaan komt is niet belangrijk, WEL is belangrijk dat de data correct is, dus is verkregen uit de centrale application state, waar die zich ook moge bevinden.

quote:
Al met al blijf ik van mening dat de DataSet wel degelijk een nuttige basis kan bieden voor een breed scala aan interessante applicaties. Maar goed, al met al is dat niet eens de rede dat ik (weer) zoveel tijd besteed aan deze post, ik ben eigenlijk niet eens een grote fan van de DataSet, maar gelukkig ben ik wel in staat met enige nuance te spreken over de verschillende technologieen.

Ja jij snapt het wel, ik niet. Gebruik je toch fijn de dataset en negeer je mijn punten toch fijn? Jij kunt inderdaad met veel nuance spreken over technologieen, vooral als ze geen reet met het punt te maken hebben wat ter discussie lag.

quote:
Mijn ervaring is dat meer ervaring op welk vakgebied dan ook leidt tot meer nuance. Zaken zijn niet zwart/wit, goed/fout of ja/nee. Dat is dan ook juist de rede dat ik me zo stoorde aan de volstrekt ongenuanceerde posts van EfBe.

Aggut, je stoorde je aan mij? Ik heb beargumenteerd waarom ik mijn standpunt had, en daar heb je geen speld tussen weten te krijgen, je raaskalt wat over onderwerpen die er totaal niet mee te maken hebben. Ik heb, maar daar ben je ongetwijfeld blind voor, ook aangegeven dat bv de dataset WEL nuttig kan zijn in sommige situaties, en dat ervaren ontwikkelaars in multi-user applicaties de bezwaren van het stateful programmeren in een stateless omgeving wel inzien en er rekening mee houden. Hoezo geen nuancering?

Ik proef uit je opmerking dat je jezelf (heb het maar even bold gemaakt) erg geweldig vindt en jezelf erg veel ervaring toedicht, en deze kennelijk niet bespeurt bij mij. Laat ik me daar verder niet over uitlaten, maar alleen zeggen dat zodra je iemand's mening arrogant vindt je geen blijk geeft van veel kennis en kunde.

quote:
Los van de in mijn ogen domweg onbeschofte en onnodig belerende taal die de man nu en in het verleden richting mij heeft geuit vind ik het nog steeds buitengewoon arrogant om zaken zo ongenuanceerd neer te zetten als hij heeft gedaan in deze thread.
Fucking hell, wie begon hier over arrogant en onbeschofte taal? Ik heb alle stellingen onderbouwt met argumenten en ik ben ZEER SERIEUS als ik zeg dat de DataSet een EVIL object is omdat het VEEL developers die niet zo ervaren zijn de gevaren niet in laat zien, waardoor veel applicaties het gevaar lopen niet te werken en dat de fout nauwelijks is te achterhalen.

Al wat jij doet is, nu en in een vorige thread over de datareader (die je kennelijk zelf bedacht hebt, zo was je aangevallen door een negatieve mening erover die onderbouwt was met ARGUMENTEN), mij afzeiken alszou ik arrogant zijn, belerend en onbeschoft, niet zoveel ervaring hebben (want anders was ik wel genuanceerder) en nauwelijks met argumenten komen.

Wat moet het leven zwaar zijn als je zo stronteigenwijs en egocentrisch bent als jij.

quote:
Vanmiddag viel mij plots z'n signature op: 'Fowler is een prutser'. Hoewel de referenties aan Fowler in dit forum mij zo onderhand ook gaan vervelen vind ik dit toch wel weer erg typisch.....
Wellicht moet je even op de link klikken en het artikel lezen en dan na gaan denken over waarom ik dat zou kunnen denken. Maar ik heb de vrees dat je het niet zult begrijpen.

Lead developer of LLBLGen Pro, the productive O/R mapper for .NET
My .NET Blog | Twitter


  • xoror
  • Registratie: november 1999
  • Laatst online: 17-08 14:17

xoror

Makoto!

interessant onderwerp :)

Ik maak zelf ook multi user apps en ik stoor me idd ook mateloos aan datasets. In dit geval borlands implementatie. Maar ik zie dat het veel overeenkomsten heeft met implementatie van ms.

Voor de volgende revisie (zucht:) ) van mijn software wil ik overschakelen naar
een disconnected (in ms termen) model. Om 'ongewenste' wijzigingen de baas te zijn wil ik per table een timestamp oid bijhouden. Je mag dan alleen updaten als je over de juiste timestamp beschikt. Ik geef toe dat het geen mooie oplossing is, maar ik heb nog geen betere voorlopig gezien. Nadeel van deze methode is dat voordat je een wijziging wil doorvoeren eerst de betreffende row moet refreshen. of gewoon proberen te committen en fout opvangen.

  • maikel
  • Registratie: januari 2001
  • Laatst online: 21-11 14:47
quote:
xoror schreef op 18 april 2003 @ 12:47:
interessant onderwerp :)

Ik maak zelf ook multi user apps en ik stoor me idd ook mateloos aan datasets. In dit geval borlands implementatie. Maar ik zie dat het veel overeenkomsten heeft met implementatie van ms.

Voor de volgende revisie (zucht:) ) van mijn software wil ik overschakelen naar
een disconnected (in ms termen) model. Om 'ongewenste' wijzigingen de baas te zijn wil ik per table een timestamp oid bijhouden. Je mag dan alleen updaten als je over de juiste timestamp beschikt. Ik geef toe dat het geen mooie oplossing is, maar ik heb nog geen betere voorlopig gezien. Nadeel van deze methode is dat voordat je een wijziging wil doorvoeren eerst de betreffende row moet refreshen. of gewoon proberen te committen en fout opvangen.


Als je datasets gebruikt heb je dat probleem met ongewenste wijzigingen niet: als je update, gebruikt de dataset 'optimistic concurrency' (update.... where waarde1=[oude waarde1] AND waarde2=[oude waarde2]). Hierdoor worden wijzigingen alleen doorgevoerd indien de data tussendoor niet gewijzigd is.
Indien de data toch gewijzigd is, kun je via de dataset een table verkrijgen met daarin alle rijen waarbij de wijzigingen niet doorgevoerd zijn. Deze zou je dus netjes aan de gebruiken kunnen tonen, zodat deze kan beslissen om de wijzigingen alsnog door te voeren of niet.

  • Scare360
  • Registratie: juli 2001
  • Laatst online: 08:38
quote:
paullooijmans schreef op 18 April 2003 @ 02:07:
Hoewel de referenties aan Fowler in dit forum mij zo onderhand ook gaan vervelen vind ik dit toch wel weer erg typisch.....


Wij doen ons uiterste best om de communicatie tussen de software engineers postende op tweakers te verbeteren. Fowler met PEA, GoF met Patterns bieden vaak net genoeg houvast om mee te doen in de discussie, vandaar dat bij beschrijven van oplossing vaak verwezen wordt naar een van de twee.

Scheelt weer in de "wij hebben het over hetzelfde, maar weten dat nog niet" discussies.

Pattern-centric is a good thing!

Ik hoor trouwens niemand over de OnRowUpdated, RowError, SkipCurrentRow. Op zich is concurrency redelijk af te vangen binnen een DataSet, maar het levert naar mijn smaak absolute hack code op. In een beetje framework ga je je gebruikers niet vervelen met "je kan niet schrijven want", op de achtergrond retries slingeren maakt het vaaknog veel erger.

Iemand haalt een business ent (ref) op en modificeert een member, IsStale = false, Zodra iemand anders leest of net iets later wil modificeren check je op IsStale. De gebruiker weet dan dat, dat object gelocked is. De cache pool schrijft het object zodra die weer aangeboden wordt voor opslag. Oftewel DataMapper. Kijk anders eens in de Stockupdates demo van MS, daar hebben ze een enum ingebouwd om op business process niveau deze zaken naar de gebruiker te vertalen.

Wat zijn enterprise applicaties toch een mooi vakgebied :)

PSN (PS4): Scare360


  • EfBe
  • Registratie: januari 2000
  • Niet online
quote:
maikel schreef op 18 April 2003 @ 12:57:
Als je datasets gebruikt heb je dat probleem met ongewenste wijzigingen niet: als je update, gebruikt de dataset 'optimistic concurrency' (update.... where waarde1=[oude waarde1] AND waarde2=[oude waarde2]). Hierdoor worden wijzigingen alleen doorgevoerd indien de data tussendoor niet gewijzigd is.
Indien de data toch gewijzigd is, kun je via de dataset een table verkrijgen met daarin alle rijen waarbij de wijzigingen niet doorgevoerd zijn. Deze zou je dus netjes aan de gebruiken kunnen tonen, zodat deze kan beslissen om de wijzigingen alsnog door te voeren of niet.

Dit is toch een situatie die je niet wilt? Klassiek voorbeeld:

Personen A en B willen record R wijzigen. Persoon A is van het langzame type, persoon B van het snelle type. Persoon A is echter eerder op zn werk en begint met editen van record R. Na een delta T begint B met het editen van R. Omdat dit tijdrovend is, duurt dit nogal lang. A is langzamer dan B in dit werkje, en B is dus eerder klaar. Omdat R nog niet is gewijzigd in de tijd dat B met R, kan B R gewoon updaten. R is nu gewijzigd. A is na B pas klaar en wil ook updaten. *rrrrt!* mag niet, want R is gewijzigd sinds A bezig is geweest met R. A heeft dus werk voor niets zitten doen, want kan zijn wijzigingen niet doorvoeren.

Nu opper jij dat je dan die wijzigingen alsnog door kan voeren. A heeft een tijdje gespendeerd aan het wijzigen van R en gaat dan echt niet zeggen "ok, dan niet", maar wijzigt R met zijn wijzigingen, welke dus de wijzigingen van B teniet doet. Ergo: jouw oplossing werkt ook niet, want ongeacht wie, verliest een van beide personen tijd, omdat zijn werk wordt overschreven.

BETER zou zijn als slechts 1 persoon wijzigingen kan doorvoeren op R, dus kan beginnen met de wijzigingen van R, in dit geval A. B kan dus daar niet mee aanvangen en verliest dus geen tijd door wijzigingen door te voeren aan R die worden overschreven door de wijzigingen van A. A verliest geen tijd en geen wijzigingen omdat optimistic locking hem belet de wijzigingen door te voeren.

Je ziet dus een organisatorisch probleem ipv een technisch probleem: 2 personen willen hetzelfde wijzigen op hetzelfde moment: beter zou zijn dus dat 1 persoon de wijzigingen opgelegd aan zowel A als B doorvoert op R, zodat de andere persoon ander werk kan doen, bv wijzigingen aan een ander record. Hierdoor werkt je organisatie sneller en efficienter.

Een van beide te beletten hun gedane werk af te ronden is op zijn zachtst gezegd 'the easy way out' en pure symptoombestrijding van het werkelijke fenomeen: een organisatorisch probleem. Om een open deur nog verder open te trappen: automatisering is er om organisatorische problemen op te lossen, en dan middels IT wat symptoombestrijdingsmiddelen in de strijd te gooien lost niets op, integendeel: men creeert een gevoel van 'het is efficienter', het kost geld maar er is niets veranderd.

Lead developer of LLBLGen Pro, the productive O/R mapper for .NET
My .NET Blog | Twitter


  • EfBe
  • Registratie: januari 2000
  • Niet online
quote:
paulgielens schreef op 18 april 2003 @ 13:04:
Wij doen ons uiterste best om de communicatie tussen de software engineers postende op tweakers te verbeteren. Fowler met PEA, GoF met Patterns bieden vaak net genoeg houvast om mee te doen in de discussie, vandaar dat bij beschrijven van oplossing vaak verwezen wordt naar een van de twee.
Scheelt weer in de "wij hebben het over hetzelfde, maar weten dat nog niet" discussies.

Ik las een review van Fowlers PEA boek en daar had iemand het over precies dit onderwerp: Fowlers boek was niet zozeer uniek qua inhoud maar wel dat het mensen aanzet tot het uniform benoemen van veel voorkomende designoplossingen. Echter, aldus die reviewer, bleek dat onder veel software designers de benamingen uit het GoF boek (heb het vanochtend binnengekregen, mijn 1e indruk is: erg goed boek) nog niet eens meester zijn en dat Fowler, wellicht onbedoeld, nieuwe namen introduceert voor zaken die ook in het GoF boek voorkomen, waardoor je nog meer spraakverwarring krijgt :). Maar het streven is wel nobel.

quote:
Ik hoor trouwens niemand over de OnRowUpdated, RowError, SkipCurrentRow. Op zich is concurrency redelijk af te vangen binnen een DataSet, maar het levert naar mijn smaak absolute hack code op. In een beetje framework ga je je gebruikers niet vervelen met "je kan niet schrijven want", op de achtergrond retries slingeren maakt het vaaknog veel erger.

PRECIES! Zie mijn voorbeeld hierboven. Het is niet het probleem van de gebruiker dat hij eerst werk verricht (dus tijd investeert) en daarna die tijd (en dus die investering) verloren ziet gaan omdat het systeem hem belet de investering te verzilveren.

Om even in mijn arrogante, belerende, botte boerenwoorden te spreken: het is een typisch voorbeeld van SLECHT design en een voorbeeld van slechte automatisering.

quote:
Iemand haalt een business ent (ref) op en modificeert een member, IsStale = false, Zodra iemand anders leest of net iets later wil modificeren check je op IsStale. De gebruiker weet dan dat, dat object gelocked is. De cache pool schrijft het object zodra die weer aangeboden wordt voor opslag. Oftewel DataMapper. Kijk anders eens in de Stockupdates demo van MS, daar hebben ze een enum ingebouwd om op business process niveau deze zaken naar de gebruiker te vertalen.

Het is wel zaak dit ook centraal te regelen en niet op gui niveau. Dit ivm bv webservices die andere applicaties voorzien van data uit dezelfde bron (dezelfde database) en zodoende niet doorhebben dat het is gelocked. Op database niveau dmv een serialized transaction is imho de te prefereren weg: op die manier kun je elk willekeurig systeem laten werken met dezelfde database op een concurrent manier zonder dat je op een hoger niveau allerlei communicatie moet opzetten tussen systemen, die eigenlijk behalve de database niets gemeen hebben.

quote:
Wat zijn enterprise applicaties toch een mooi vakgebied :)
Er zit veel in, veel meer dan sommige mensen denken. Verder is het ook erg simpel, als je simpele, maar doeltreffende manieren gebruikt om het je zo simpel mogelijk te maken. Helaas begaan veel mensen standaard fouten zoals in het ontwerp meenemen van platform-specifieke zaken zoals "Dat soort designs zijn traag.", en andere dooddoeners die niet gerelateerd zijn aan een ontwerp maar aan de implementatie ervan.

Lead developer of LLBLGen Pro, the productive O/R mapper for .NET
My .NET Blog | Twitter


  • xoror
  • Registratie: november 1999
  • Laatst online: 17-08 14:17

xoror

Makoto!

quote:
EfBe schreef op 18 april 2003 @ 13:37:
[...]

Dit is toch een situatie die je niet wilt? Klassiek voorbeeld:

Personen A en B willen record R wijzigen. Persoon A is van het langzame type, persoon B van het snelle type. Persoon A is echter eerder op zn werk en begint met editen van record R. Na een delta T begint B met het editen van R. Omdat dit tijdrovend is, duurt dit nogal lang. A is langzamer dan B in dit werkje, en B is dus eerder klaar. Omdat R nog niet is gewijzigd in de tijd dat B met R, kan B R gewoon updaten. R is nu gewijzigd. A is na B pas klaar en wil ook updaten. *rrrrt!* mag niet, want R is gewijzigd sinds A bezig is geweest met R. A heeft dus werk voor niets zitten doen, want kan zijn wijzigingen niet doorvoeren.

Nu opper jij dat je dan die wijzigingen alsnog door kan voeren. A heeft een tijdje gespendeerd aan het wijzigen van R en gaat dan echt niet zeggen "ok, dan niet", maar wijzigt R met zijn wijzigingen, welke dus de wijzigingen van B teniet doet. Ergo: jouw oplossing werkt ook niet, want ongeacht wie, verliest een van beide personen tijd, omdat zijn werk wordt overschreven.

BETER zou zijn als slechts 1 persoon wijzigingen kan doorvoeren op R, dus kan beginnen met de wijzigingen van R, in dit geval A. B kan dus daar niet mee aanvangen en verliest dus geen tijd door wijzigingen door te voeren aan R die worden overschreven door de wijzigingen van A. A verliest geen tijd en geen wijzigingen omdat optimistic locking hem belet de wijzigingen door te voeren.

Je ziet dus een organisatorisch probleem ipv een technisch probleem: 2 personen willen hetzelfde wijzigen op hetzelfde moment: beter zou zijn dus dat 1 persoon de wijzigingen opgelegd aan zowel A als B doorvoert op R, zodat de andere persoon ander werk kan doen, bv wijzigingen aan een ander record. Hierdoor werkt je organisatie sneller en efficienter.

Een van beide te beletten hun gedane werk af te ronden is op zijn zachtst gezegd 'the easy way out' en pure symptoombestrijding van het werkelijke fenomeen: een organisatorisch probleem. Om een open deur nog verder open te trappen: automatisering is er om organisatorische problemen op te lossen, en dan middels IT wat symptoombestrijdingsmiddelen in de strijd te gooien lost niets op, integendeel: men creeert een gevoel van 'het is efficienter', het kost geld maar er is niets veranderd.
precies, met dit probleem stoei ik nog steeds. sommige bewerkingen kosten gewoon veel tijd en is zonde als dat opnieuw gedaan moet worden.

  • Scare360
  • Registratie: juli 2001
  • Laatst online: 08:38
quote:
EfBe schreef op 18 april 2003 @ 13:46:

Ik las een review van Fowlers PEA boek en daar had iemand het over precies dit onderwerp: Fowlers boek was niet zozeer uniek qua inhoud maar wel dat het mensen aanzet tot het uniform benoemen van veel voorkomende designoplossingen. Echter, aldus die reviewer, bleek dat onder veel software designers de benamingen uit het GoF boek (heb het vanochtend binnengekregen, mijn 1e indruk is: erg goed boek) nog niet eens meester zijn en dat Fowler, wellicht onbedoeld, nieuwe namen introduceert voor zaken die ook in het GoF boek voorkomen, waardoor je nog meer spraakverwarring krijgt :). Maar het streven is wel nobel.


Fowler geeft steeds nadrukkelijk aan dat het in GoF of de Java wereld zus en zo genoemd wordt en waarom hij specifiek voor een andere naam gekozen heeft. Ik ben nog steeds van mening dat je beide boeken met de nodige objectiviteit moet lezen en er dan een hele hoop van kan leren. Microsoft heeft te kennen gegeven dat Fowler beter had kunnen wachten, omdat hij oplossingen aanprijst waar het .NET framework betere alternatieven voor biedt. MS wil naar DataSet's en Typed DataSet's en Fowler geeft gewoon duidelijk weer waarom je dat eens niet zou moeten doen.


quote:
Het is wel zaak dit ook centraal te regelen en niet op gui niveau. Dit ivm bv webservices die andere applicaties voorzien van data uit dezelfde bron (dezelfde database) en zodoende niet doorhebben dat het is gelocked. Op database niveau dmv een serialized transaction is imho de te prefereren weg: op die manier kun je elk willekeurig systeem laten werken met dezelfde database op een concurrent manier zonder dat je op een hoger niveau allerlei communicatie moet opzetten tussen systemen, die eigenlijk behalve de database niets gemeen hebben.


Als de entiteit niet mee "vote" binnen een business process moet je manueel een transactie inbouwen en zeker niet alles zomaar binnen de DTC laten draaien. Gewoon zo laag mogelijk de contecxt opbouwen. Waar ik nu werk gaat alles vanaf de UI transactioneel binnen de DTC, over slecht design gesproken ;)

Een Business server met een business process API, waaronder een pool van business objecten draaien (DataSet, Typed DataSet, Custom Entity), met daarachter een mapping framework of een DAL component had ik hierbij in gedachten. Je linkt de interfaces van je business componenten mee op de client. Of gewoon alles lekker stateless houden en vertrouwen op je DAL, probleem is als je een complex domein model hebt je toch snel statefull qua entiteiten gaat denken en bouwen. Hier komt MS dus vet te kort, er is niet een fatsoenlijk voorbeeld te vinden met een degelijk oo-model d'r aan ten grondslag.


quote:
Er zit veel in, veel meer dan sommige mensen denken.

Iedereen zou verplicht:
Distributed Systems Concept and Design (Coulouris, Dollimore, Kindber) [0-201-61918-0] Moeten lezen!

De discussie die we hier voeren is pure theorie en we vechten om de meningsverschillen m.b.t. voorhanden technische oplossing. Slechte zaak imo.

PSN (PS4): Scare360


  • Scare360
  • Registratie: juli 2001
  • Laatst online: 08:38
quote:
xoror schreef op 18 april 2003 @ 14:59:
precies, met dit probleem stoei ik nog steeds. sommige bewerkingen kosten gewoon veel tijd en is zonde als dat opnieuw gedaan moet worden.
Kijk eens naar de client code van TaskVision, daar wordt dit probleem ook min of meer opgelost.

PSN (PS4): Scare360


  • paullooijmans
  • Registratie: februari 2003
  • Laatst online: 08-02-2007
Ik was eigenlijk niet van plan te reageren vanwege de wederom stuitende toon van de posts van EfBe, maar ik realiseerde me dat dit gezien zou kunnen worden als toegeven en, nog erger, het zou EfBe het idee kunnen geven dat hij met overmatig geblaas en beledigingen een discussie zou kunnen winnen.
quote:

Het heeft geen ene reet met concurrency te maken. Concurrency is het concept dat je hanteert wanneer 2 of meer users tegelijk DEZELFDE data aan het modificeren zijn

[...]

DIT probleem is iets heel anders, het gaat nl. over versnippering van applications state en ik heb met opzet een voorbeeld genomen waar geen concurrency probleem in zit, nl. beide users werken wel op dezelfde table maar op verschillende rows.

[...]

Echter heeft dit NIETS te maken met stateful vs stateless wat de eigenlijke discussie was.


Incorrect. De definitie van concurrency die jij gebruikt slaat puur op databases, ik heb het over concurrency in een andere context, namelijk in de 'cached data' context waar we het hier juist over hebben, zoals jij zelf al stelt, misschien is het een idee je eigen posts eens goed te lezen!!! Het enforcen van constraints en het zorgen voor correcte data in de verschillende caches valt wel degelijk onder de noemer concurrency in die context, ik nam aan dat jouw engels voldoende is om te begrijpen dat concurrency een concept is dat zich voor kan doen in meerdere scenarios (threading, databases, cached data, etc) en dat het niet slaat op database pur sang. Ik neem juist het voorbeeld van de 'double write' omdat dit het 'worst case' scenario is in cached data concurrency en heb mi voldoende bewezen dat DataSets voor dit probleem een correcte oplossing bieden.


quote:
Oh, dus wanneer ik datasets ga gebruiken draait mijn systeem qua performance beter? Ik moet 2(!) keer mijn wijzigingen doorvoeren en als de 2e keer mislukt (in de database) dan moet ik de 1e handmatig terugrollen.


Afhankelijk van je applicatie kan de DataSet, ondank dat deze +/- 4x langzamer is dan de DataReader, wel degelijk een positieve invloed hebben op performance maar veel meer nog op scalability. Neem het voorbeeld van postbacks in webforms: het gegeven dat je een dataset in de viewstate van een pagina kan zetten kan in een scenario waarbij er veel postbacks zijn het aantal SELECT statements heel erg terugbrengen, zaken als paging en sorting kunnen allemaal los van de database gebeuren, die zich kan concentreren op belangrijkere zaken dan het vele malen produceren van dezelfde data.

quote:

Het oplossen van concurrency doe je niet door het gebruik van de dataset!

[....]

Ik dender overigens de data van B vrolijk over A heen, het is nl. lood om oud ijzer. Als de data van A behouden moet blijven bouw ik een locking mechanisme in op functioneel niveau.


DataSets bieden 'out of the box', zonder een extra regel code te hoeven schrijven, een goede bescherming tegen database concurrency. Omdat database-concurrency offtopic is zal ik er hier niet al te veel op in gaan, ik volsta met te zeggen dat jij blijkbaar de relatief grote tijdsinvestering en talloze gevaren van zelfgebouwde pessimistic locking prefereert boven de eenvoudige, elegante en relatief 'fale-safe' oplossing van optimistic locking, en dat voor een situatie die zelfs bij relatief veelgebruikte applicaties slechts zelden voorkomt!

quote:

Wat je nodig hebt zijn objects die het gemakkelijk maken entiteiten te modificeren/toe te voegen/te verwijderen in de central state repository, normaliter de database.

[...]

Verder als ik vele datasources wil combineren dan doe ik dat IN de dal, de BL werkt t.a.t. met 'data' in een vorm die het beste voor de BL te hanteren is, waar die vandaan komt is niet belangrijk, WEL is belangrijk dat de data correct is, dus is verkregen uit de centrale application state, waar die zich ook moge bevinden.


Je begrijpt het echt niet he? De DataSet IS JE DAL!!!!!!! Boven op een typed DataSet kun je uitstekend een goede BLL bouwen. Daarin is het JOUW VERANTWOORDELIJKHEID dat de data op het juiste tijdstip 'ververst' wordt uit de DB, dit is 1 METHOD CALL!

DataAdapter.Fill(dataSet)

Welk onderdeel van bovenstaande regel begrijp je niet? Hiermee kun jij ten alle tijden zorgen dat je DataSet up to date is! Welke versnippering vindt er dan plaats? Geen! Zoals Maikel als zei, het komt er gewoon op neer dat je dit bijvoorbeeld in je Page_Load oproept, dan vindt er GEEN versnippering plaats en heb je ALTIJD de laatst mogelijk DB state.

quote:

JIJ zegt nu dat in mijn ellenlange posting geen oplossing staat voor dit probleem. Dat staat er wel. Lees hem nog maar een keer door.

[...]

Als je bv collections van 'customers' in memory houdt en daar eerst een setje 'customer' objects aantoevoegt, dan 'save' aanroept van die objects, is dat uiteraard exact eender aan een dataset en daar wat rijen aan toevoegen, de rij in de dataset heeft alleen een andere gedaante, maar de problemen die ermee spelen zijn precies dezelfde.


Lees jij je eigen post nog maar een keer door EfBe! Je geeft hier volgens mij toch echt zelf toe dat jouw oplossingen niet PER DEFINITIE het probleem oplossen! Het probleem ligt bij de ontwikkelaar, die net zo goed een collectie customers in de viewstate/session kan zetten als een DataSet!

En DAAROM ben ik het niet met je eens als je zegt dat de DataSet een van de domste technologieen ooit is! Mits goed gebruikt is de DataSet een snelle manier om een eenvoudige DAL te maken en een goede basis voor allerlei mooie technologieen zoals bijv. ObjectSpaces. Daarnaast kan hij je erg veel tijd besparen als je snel een database-driven applicatie in elkaar wilt 'slepen'.

Ik ben niet eens een fan van de DataSet, toen ik moest kiezen welke data-access methode we gingen gebruiken in ons eigen O/R framework was de keuze voor DataReader snel gemaakt, maar de DataSet is wel degelijk een goede keus in veel scenarios. (@paul gielens: ik was in de veronderstelling dat je er niet meer mee bezig was, stuur je mail nog eens, misschien is hij in het verkeerde foldertje terecht gekomen in mijn Outlook)

Ik zou het uitermate slecht vinden als beginnende (.NET) programmeurs hier in het Tweakers forum gingen zoeken naar DataSet en daar EfBe's (in mijn ogen) ongefundeerde 'anti-dataset-rant' tegenkwamen zonder enige vorm van tegenspraak. Het KAN wel degelijk een goede basis zijn voor DAL code, mits op de juiste manier gebruikt: Dat is de essentie van mijn betoog.

EfBe is geweldig !


  • EfBe
  • Registratie: januari 2000
  • Niet online
Vanwege je sig heb ik je gemeld in Schop een modje.

Ik heb veel tijd besteed aan het oprecht onderbouwen van mijn stelling. Dat je het daar dan niet mee eens bent, dat is niet zo erg. Dat je dat moet uiten in zeer denigrerende statements en je signature: "EfBe is een prutser" snap ik niet. Kennelijk heb je dat soort dingen nodig om je punt te maken. Ik laat deze thread nu verder links liggen en jou ook.

Mocht je niet gebanned worden van dit forum, dan wil ik je vragen niet meer op mijn postings te reageren in andere threads. Je mag van mij deze discussie 'winnen' hoor, als het je daar om te doen is, en dat gevoel krijg ik sterk. Ik bediscussieer met veel mensen deze materie, maar jij bent de enige, hier en in real life, die met de hakken in het zand met het vuur alsof de familie-eer is aangetast, de discussie ingaat. Kennelijk denk je dat wanneer je het niet met mij eens bent en je mijn punt in jouw ogen te weinig naar voren kunt brengen, je voor prutser wordt aangezien oid.

(als laatste note: stateful vs stateless is de term voor het bediscussieerde, niet 'concurrency'. Zoals jij het brengt valt alles onder concurrency, terwijl concurrency de term is om aan te duiden hoe je omgaat met simultaan gedane mutaties op een centrale repository)

EfBe wijzigde deze reactie 20-04-2003 11:32 (129%)

Lead developer of LLBLGen Pro, the productive O/R mapper for .NET
My .NET Blog | Twitter


  • Scare360
  • Registratie: juli 2001
  • Laatst online: 08:38
offtopic:
[quote]stuur je mail nog eens[/quote]
done

PSN (PS4): Scare360


  • whoami
  • Registratie: december 2000
  • Laatst online: 08:07
quote:
paullooijmans schreef op 20 April 2003 @ 01:43:

Afhankelijk van je applicatie kan de DataSet, ondank dat deze +/- 4x langzamer is dan de DataReader, wel degelijk een positieve invloed hebben op performance maar veel meer nog op scalability. Neem het voorbeeld van postbacks in webforms: het gegeven dat je een dataset in de viewstate van een pagina kan zetten kan in een scenario waarbij er veel postbacks zijn het aantal SELECT statements heel erg terugbrengen, zaken als paging en sorting kunnen allemaal los van de database gebeuren, die zich kan concentreren op belangrijkere zaken dan het vele malen produceren van dezelfde data.

Ja maar, wat als die data ondertussen al veranderd is ? Als je je dataset in de viewstate houdt, en niet refreshed, wat dan?
Ik vind dat EfBe daar wel een punt heeft.


quote:
DataSets bieden 'out of the box', zonder een extra regel code te hoeven schrijven, een goede bescherming tegen database concurrency. Omdat database-concurrency offtopic is zal ik er hier niet al te veel op in gaan, ik volsta met te zeggen dat jij blijkbaar de relatief grote tijdsinvestering en talloze gevaren van zelfgebouwde pessimistic locking prefereert boven de eenvoudige, elegante en relatief 'fale-safe' oplossing van optimistic locking, en dat voor een situatie die zelfs bij relatief veelgebruikte applicaties slechts zelden voorkomt!

Hoe bieden ze daar dan bescherming tegen aan?


quote:

DataAdapter.Fill(dataSet)

Welk onderdeel van bovenstaande regel begrijp je niet? Hiermee kun jij ten alle tijden zorgen dat je DataSet up to date is! Welke versnippering vindt er dan plaats? Geen! Zoals Maikel als zei, het komt er gewoon op neer dat je dit bijvoorbeeld in je Page_Load oproept, dan vindt er GEEN versnippering plaats en heb je ALTIJD de laatst mogelijk DB state.
Daarnet zei je nog dat je de DataSet in je viewstate hield, om zo bij een postback minder queries te moeten doen op je DB.

DevLog - FotoLog


  • Scare360
  • Registratie: juli 2001
  • Laatst online: 08:38
quote:
whoami schreef op 20 april 2003 @ 11:22:

Hoe bieden ze daar dan bescherming tegen aan?

Daarnet zei je nog dat je de DataSet in je viewstate hield, om zo bij een postback minder queries te moeten doen op je DB.


DataSet ondersteund optimistic concurrency door exposen van events (kort door de bocht).

lees meer hier

Bij de dataset heb je iig de keuze, iedere client kan zijn eigen verantwoordelijkheid nemen tegen de DataSet aan. De ene keer volstaat een dirty view, andere keer wil je een clean read forceren.

PSN (PS4): Scare360


  • Alarmnummer
  • Registratie: juli 2001
  • Laatst online: 05-11 10:28

Alarmnummer

-= Tja =-

quote:
EfBe schreef op 18 April 2003 @ 13:46:
[...]
Ik las een review van Fowlers PEA boek en daar had iemand het over precies dit onderwerp: Fowlers boek was niet zozeer uniek qua inhoud maar wel dat het mensen aanzet tot het uniform benoemen van veel voorkomende designoplossingen.

In dat en vele andere boeken zegt hij ook dat hij niet de bedenker is van die kennis. Hij is gewoon een goeie schrijver.


quote:
Echter, aldus die reviewer, bleek dat onder veel software designers de benamingen uit het GoF boek (heb het vanochtend binnengekregen, mijn 1e indruk is: erg goed boek) nog niet eens meester zijn en dat Fowler, wellicht onbedoeld, nieuwe namen introduceert voor zaken die ook in het GoF boek voorkomen, waardoor je nog meer spraakverwarring krijgt :). Maar het streven is wel nobel.
Hij introduceert zeker geen nieuwe namen en verder zijn zijn patterns ook niet op hetzelfde abstractie nivo als die van GoF. Zijn design patterns uit 'Enterprise Patterns' zijn veel meer gericht op enterprise applicaties en die van GoF zijn meer algemeen. Trouwens als hij andere namen zou introduceren dan zou hij denk ik vanuit de oo wereld worden afgschoten. Omdat het juist de bedoeling is dat je er makkelijk over kan praten doordat de namen consistent zijn.

Alarmnummer wijzigde deze reactie 20-04-2003 11:32 (4%)


  • EfBe
  • Registratie: januari 2000
  • Niet online
Ik zei ook: "Aldus die reviewer", ik ken het boek inhoudelijk niet. Heb wel de patterns op Fowler's site bekeken, waarbij ik de indruk kreeg dat het er veel zijn, maar veel zijn toch wel erg hetzelfde (dwz: hetzelfde probleem op ong. dezelfde manier opgelost maar dan met een pattern dat niet hetzelfde was volgens het lijstje patterns).

Lead developer of LLBLGen Pro, the productive O/R mapper for .NET
My .NET Blog | Twitter


  • whoami
  • Registratie: december 2000
  • Laatst online: 08:07
quote:
Alarmnummer schreef op 20 April 2003 @ 11:29:
[...]

Hij introduceert zeker geen nieuwe namen en verder zijn zijn patterns ook niet op hetzelfde abstractie nivo als die van GoF. Zijn design patterns uit 'Enterprise Patterns' zijn veel meer gericht op enterprise applicaties en die van GoF zijn meer algemeen. Trouwens als hij andere namen zou introduceren dan zou hij denk ik vanuit de oo wereld worden afgschoten. Omdat het juist de bedoeling is dat je er makkelijk over kan praten doordat de namen consistent zijn.


Om hier nog ff op in te spelen:

In dat EAP boek verwijst Fowler naar de patterns uit het GoF boek als die kunnen gebruikt worden in 'zijn' patronen.
Zoals Alarmnummer al zegt zijn de patterns die Fowler beschrijft op een ander abstractie-niveau en kunnen de GoF patterns in die patterns gebruikt worden. Als Fowler naar de GoF patterns verwijst, doet hij dat ook met de naam waarmee ze in het GoF boek staan.

quote:
EfBe schreef op 20 april 2003 @ 11:36:
Ik zei ook: "Aldus die reviewer", ik ken het boek inhoudelijk niet. Heb wel de patterns op Fowler's site bekeken, waarbij ik de indruk kreeg dat het er veel zijn, maar veel zijn toch wel erg hetzelfde (dwz: hetzelfde probleem op ong. dezelfde manier opgelost maar dan met een pattern dat niet hetzelfde was volgens het lijstje patterns).
Idd. Hij bespreekt 'problemen' die een ontwikkelaar kan tegenkomen (zoals bv. een manier om de BLL voor te stellen, of de communicatie tsn BLL en DAL, of hoe je een OO inheritance model in een RDBMS kunt voorstellen), en dan heeft hij verschillende patronen beschreven om dat probleem te tackelen. Met telkens de voor- en nadelen en in welke situatie je best optie A of B of n kunt gebruiken.

whoami wijzigde deze reactie 20-04-2003 11:38 (30%)

DevLog - FotoLog


  • Scare360
  • Registratie: juli 2001
  • Laatst online: 08:38
quote:
EfBe schreef op 20 April 2003 @ 11:14:
Vanwege je sig heb ik je gemeld in Schop een modje.
offtopic:
Omdat Fowler hier niet post kan zijn naam wel in een denigrerende sig verwerkt worden? Sorry, ik heb m'n paasbril op vandaag, dus ik kijk er nog wel eens naast. Ff voor de duidelijkheid, ik vond deze iets wat hete discussie zeer verhelderend. Met dank van de achterban dus.

PSN (PS4): Scare360


  • whoami
  • Registratie: december 2000
  • Laatst online: 08:07
quote:
paulgielens schreef op 20 april 2003 @ 11:46:
[...]


offtopic:
Omdat Fowler hier niet post kan zijn naam wel in een denigrerende sig verwerkt worden? Sorry, ik heb m'n paasbril op vandaag, dus ik kijk er nog wel eens naast. Ff voor de duidelijkheid, ik vond deze iets wat hete discussie zeer verhelderend. Met dank van de achterban dus.
offtopic:
EfBe's sig kan ook als denigrerend beschouwd worden, echter, die prutser in z'n sig is een link waarmee EfBe z'n mening onderbouwd....

DevLog - FotoLog


  • Scare360
  • Registratie: juli 2001
  • Laatst online: 08:38
quote:
whoami schreef op 20 April 2003 @ 11:49:
offtopic:
EfBe's sig kan ook als denigrerend beschouwd worden, echter, die prutser in z'n sig is een link waarmee EfBe z'n mening onderbouwd....
offtopic:
Dus als paullooijmans ff de moeite neemt om te linken naar een reply van EfBe zijn we d'r. Dat zou onderbouwing zijn van zijn mening... politiek ligt ons wel denk ik :)

Scare360 wijzigde deze reactie 20-04-2003 12:05 (8%)

PSN (PS4): Scare360


  • EfBe
  • Registratie: januari 2000
  • Niet online
quote:
paulgielens schreef op 20 april 2003 @ 11:46:
Omdat Fowler hier niet post kan zijn naam wel in een denigrerende sig verwerkt worden? Sorry, ik heb m'n paasbril op vandaag, dus ik kijk er nog wel eens naast. Ff voor de duidelijkheid, ik vond deze iets wat hete discussie zeer verhelderend. Met dank van de achterban dus.

Ik heb niet voor niets een link in mijn sig geplaatst. Die link verwijst naar een artikel over evolutionairy databases, waarbij hij aanbeveelt om ad-hoc op het niveau van tabellen met database design bezig te gaan. Ik draai nu al bijna 10 jaar mee in de professionele softwarebusiness en 1 ding staat als een paal boven water: erg veel problemen met hedendaagse softwaredevelopmenttrajecten komt voort uit ad-hoc wijzigingen zonder onderbouwing van een gedegen ontwerp en/of modelwijzigingen waarop dan dus die lagere lagenwijzigingen zijn gebaseerd.

Omdat Fowler nogal op handen wordt gedragen door veel mensen is het des te schrijnender dat hij dit soort zaken expliciet propageert, immers veel mensen gaan er plompverloren vanuit dat hij daar ook gelijk in heeft, echter hij ziet totaal niet in dat je niet op lowlevel basis databasemodellen wijzigt, want dat is je model niet. Je model zit in een niam/ORM schema dat je wijzigt en waar je nieuwe tabellen uit distilleert. DAT is solide software-development, niet het ad-hoc knoeien aan tabellen en fysieke constraints in een database.

Als een developer hier vertelt dat hij ad-hoc tabellen loopt aan te passen in een database die door meerdere developers wordt gebruikt in een ontwikkeltraject wordt deze persoon ook terecht gewezen op het feit dat je zo geen software bouwt, omdat hetgeen hij aandraagt gelijk staat aan 'prutswerk': knoeien aan fysieke tabellen en constraints in een database zonder het model aan te passen. Vandaar de term prutser.

Ik vond deze discussie ook zeer verhelderend: dat je niet meer je mening ONDERBOUWD kunt brengen hier zonder en plain publique te worden afgemaakt. Een wijze les en gezien de hoeveelheid tijd die ik erin gestoken heb ook een zeer wrange les: ik had mijn tijd veel beter kunnen besteden dan hier proberen uit te leggen waarom er valkuilen zijn en waarom men erg op moet passen bij het toepassen van bepaalde technieken. Kennelijk is dat not-done en verdien je een afstraffing. Het zij zo. De volgende keer mag Paul Looijmans uitleggen met zijn jarenlange kennis van zaken hoe je enterprise applications bouwt, ik brand mijn vingers er niet meer aan hier.

Lead developer of LLBLGen Pro, the productive O/R mapper for .NET
My .NET Blog | Twitter


  • whoami
  • Registratie: december 2000
  • Laatst online: 08:07
en dan kunnen we nu terug ontopic gaan....

DevLog - FotoLog


  • EfBe
  • Registratie: januari 2000
  • Niet online
quote:
paulgielens schreef op 20 April 2003 @ 12:04:
Dus als paullooijmans ff de moeite neemt om te linken naar een reply van EfBe zijn we d'r. Dat zou onderbouwing zijn van zijn mening... politiek ligt ons wel denk ik :)

Tja. Welke posting zou dan dan moeten zijn, waar ik dingen verkondig die, wanneer toegepast in jouw ontwikkelteam, schade zouden kunnen berokkenen en je ontwikkelwerk onherstelbaar nadelig kunnen beinvloeden, Paul? Enig idee?

Ik ben ZEER SERIEUS bezig geweest in deze thread, heb erg veel tijd besteed aan het neerplanten van lappen uitleg hier, maar dat is kennelijk een aanleiding mij voor prutser uit te maken. Misschien moet ik mn postings in deze thread maar verwijderen, stel je voor dat een developer ze leest, het door mij gepropageerde! Het is maar goed dat die developer er dan op wordt gewezen dat het afkomstig is van een prutser!

Lead developer of LLBLGen Pro, the productive O/R mapper for .NET
My .NET Blog | Twitter


  • Scare360
  • Registratie: juli 2001
  • Laatst online: 08:38
quote:
EfBe schreef op 20 April 2003 @ 12:06:
Artikel over evolutionairy databases
Ben ik met je eens! Ik zeg dus ook niet dat het onterecht is, maar dat zijn allemaal persoonlijke meningen.
quote:
Ik vond deze discussie ook zeer verhelderend

Wij lezen door de crap heen zullen wel maar zeggen en pikken datgene wat "ons" aanstaat eruit.

Ik begin d'r een beetje spijt van te krijgen dat ik uberhaupt gereageerd heb, want ben dus van mening dat dit soort verhitte discussies erbij horen. Trek geen partij of hoe je dan ook wilt noemen. Het zou jammer zijn dat we jouw posts moeten missen (of een post) omdat inhoudelijk te persoonlijk gereageerd wordt op meningsverschillen. Je hebt mij niet horen zeggen dat de 'lappen' niet op prijs gesteld worden of jij een prutser zou zijn. Moeten zij de dupe worden doordat... nee, maarjah zo zit de hele maatschappij in mekaar.

On topic? Nee, ik denk dat we net op een punt zitten wat /14 belemmert van kwaliteit discussies. Mensen met meningen ipv recht toe recht aan het moet zo discussies. Dit topic wordt er zeker niet slechter van als we elkaars meningsverschillen eens uitdiepen. Software engineering is meer dan technische oplossingen.



code:
1
2
3
4
5
6
7
protected static void OnRowUpdated(object sender, SqlRowUpdatedEventArgs args)
{
  if (args.RecordsAffected == 0) 
  {
    args.Row.RowError = "Optimistic Concurrency Violation Encountered";
    args.Status = UpdateStatus.SkipCurrentRow;
  }
}



Hier word ik nou doodsbang van, maar voor een webapplicatie kan ik me nog voorstellen dat dergelijke constructies toepasbaar zijn. Voor een or-mapping framework zou dit de doodsteek zijn!

Daarentegen, pessimistic locking over gedistribueerde clients in drukke systemen levert ook weer de nodige shit, timeouts! Het komt neer op de tradeoffs, de ene situatie kun je leven met optimistic en de gebruiker wakker schudden als er "stront aan de knikker is". De andere keer wil je niet oneindig blijven retryen en lock je gewoon de boel. Timeouts voor lief nemend.

Vanuit de client gezien:
Je kan wel DUS!
Je kan wel MAAR!

Scare360 wijzigde deze reactie 20-04-2003 12:35 (14%)

PSN (PS4): Scare360


  • EfBe
  • Registratie: januari 2000
  • Niet online
quote:
paulgielens schreef op 20 April 2003 @ 12:30:
Ben ik met je eens! Ik zeg dus ook niet dat het onterecht is, maar dat zijn allemaal persoonlijke meningen.

Een betiteling is altijd een persoonlijke mening, het gaat er wel om waarop dan die persoonlijke mening is gebaseerd. Iemand een etter vinden betekent nog niet dat die persoon een prutser is.

quote:

Wij lezen door de crap heen zullen wel maar zeggen en pikken datgene wat "ons" aanstaat eruit.
Ik begin d'r een beetje spijt van te krijgen dat ik uberhaupt gereageerd heb, want ben dus van mening dat dit soort verhitte discussies erbij horen. Trek geen partij of hoe je dan ook wilt noemen. Het zou jammer zijn dat we jouw posts moeten missen (of een post) omdat inhoudelijk te persoonlijk gereageerd wordt op meningsverschillen. Je hebt mij niet horen zeggen dat de 'lappen' niet op prijs gesteld worden of jij een prutser zou zijn. Moeten zij de dupe worden doordat... nee, maarjah zo zit de hele maatschappij in mekaar.

Nou, in een discussie waarbij je weet dat je heilige huisjes gaat schenden kun je verwachten dat je reacties krijgt van de zg. blinde vinken, de mensen die wars van argumenten achter iets blijven staan, zoals de Intel / AMD / ATi / nVidia / Microsoft / Linux adepten. In deze discussie had ik dat dus totaal niet verwacht, en dan valt het wel koud op het dak, dat kan ik je wel verzekeren.

Ik snap ook werkelijk niet wat Looijmans bezielt, ik bedoel: waar gaat het toch helemaal over: het dataset-concept. Bedacht door iemand van Microsoft, en of dat nou een goed of slecht iets is. Er worden wat nadelen geopperd, iemand heeft wat voordelen en je kunt daar dan nog uren over door-emmeren wat zwaarder weegt: de voordelen of de nadelen. Ik vind het een slecht concept, en niet zozeer omdat het stateful programming in zich heeft, want dat doen er wel meer, maar dat het prominent op de voorgrond staat in het algehele data-access concept van Microsoft, en dan tellen alle nadelen wel zwaar mee, zeker als je bedenkt dat veel gebruikers van de dataset totaal niet weten wat 'stateful' inhoudt en de gevaren die dat met zich meebrengt in stateless omgevingen zoals webapplicaties.

De vorige keer zei ik dat de DataReader een evil ding was, en gaf daar een reden voor (meerdere geloof ik zelfs). Toen werd het ook al een nare discussie waarbij ik in de ogen van meneer Looijmans niet snapte waar ik het over had, en nu herhaalt de geschiedenis zich. Ik heb daar genoeg van. Ik vind het prima als mensen argumenten aandragen die mijn argumenten teniet doen, nogmaals: graag zelfs, maar kom daar dan ook mee, geef voorbeelden waarin mijn oplossing niet werkt en de dataset wel bijvoorbeeld, voorbeelden die aantonen dat mijn argumenten geen hout snijden. Maar wat blijkt? Zodra je je nek uitsteekt en mensen probeert te waarschuwen voor nadelen waar Microsoft het niet heeft en de cursusleiders al helemaal niet, komt er weer een persoon naar voren die zo intens op zn pik getrapt is, dat het net lijkt alsof ik die persoon persoonlijk heb beledigd. Zo'n reactie verwacht je in een Intel vs AMD discussie, niet in discussie over n-tier applicaties.

quote:
On topic? Nee, ik denk dat we net op een punt zitten wat /14 belemmert van kwaliteit discussies. Mensen met meningen ipv recht toe recht aan het moet zo discussies. Dit topic wordt er zeker niet slechter van als we elkaars meningsverschillen eens uitdiepen. Software engineering is meer dan technische oplossingen.
Nou, op deze manier vind ik dat 'uitdiepen' niet zo bar amusant, eerlijk gezegd. Ik ben voor open, oprechte discussies waar argumenten naar voren worden gebracht die bv aangeven dat een stelling een nauwer toepassingsgebied heeft dan gedacht. Echter, dat is m.i. hier niet meer mogelijk, althans niet als objecten uit de standaard library van .NET naar voren komen en daar kritiek op komt, want voor je het weet komt meneer Looijmans met een repliek. Het nare daaraan is dat ik geen reet met die repliek kan, behalve me kapot ergeren.

Lead developer of LLBLGen Pro, the productive O/R mapper for .NET
My .NET Blog | Twitter


  • maikel
  • Registratie: januari 2001
  • Laatst online: 21-11 14:47
De sig van paullooijmans is mijns inziens meer een parodie op je eigen sig en moet ook met een (flinke) korrel zout worden genomen. Paul heeft in dit topic ook al meerdere keren aangegeven respect te hebben voor je kennis en werk. De reden dat deze discussie zo hoog oploopt is dan ook niet dat je onzin zou uitkramen, maar je uitspraken als "DataSets zijn het domste dat ooit gebouwd is" en "MS is totaal de weg" kwijt: deze zijn nogal zwart/wit.
Paul geeft aan dat er scenario's te bedenken zijn waarin DataSets juist wel handig kunnen zijn, in de hoop dat jij je mening enigszins nuanceert. Maar je blijft toch volhouden dat DataSets en DataReaders allebei slecht/evil zijn.

Ik ben van mening dat zowel jij als Paul allebei goed weten waar jullie het over hebben en ga er dus vanuit dat jullie kennis hier op GoT erg gewaardeerd wordt.

maikel wijzigde deze reactie 20-04-2003 13:15 (13%)


  • paullooijmans
  • Registratie: februari 2003
  • Laatst online: 08-02-2007
offtopic:

Maikel slaat de spijker op zijn kop. Mijn laatste post en mijn nieuwe sig zijn inderdaad een parodie op de toon die EfBe in zijn posts gebruikt.

[quote]
Zodra je je nek uitsteekt en mensen probeert te waarschuwen voor nadelen waar Microsoft het niet heeft en de cursusleiders al helemaal niet, komt er weer een persoon naar voren die zo intens op zn pik getrapt is, dat het net lijkt alsof ik die persoon persoonlijk heb beledigd
[/quote]

Hmmm, iemand beledigen he.....hmmmm, quotes please:

[quote]
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!

[...]

Kom met argumenten of hou je mond.

[...]

Het dringt wellicht niet tot je door, maar ik weet echt wel waarover ik praat...

[...]

Je begrijpt er niet veel van geloof ik. WAT zei ik nu precies?

[...]

Als JIJ nou niet zo arrogant was geweest en mij arrogantie had verweten, had ik je dit ook wel uit willen leggen hoor.

[...]

Het heeft geen ene reet met concurrency te maken.

[...]

Je onderkent helemaal niks, je snapt niet waarover IK het had en wat onder concurrency wordt verstaan.

[...]

Dat is een flutoplossing

[...]

...misschien moet je eens op cursus en wat termen leren.

[...]

..je raaskalt wat over onderwerpen die er totaal niet mee te maken hebben.

[...]

Wat moet het leven zwaar zijn als je zo stronteigenwijs en egocentrisch bent als jij.
[/quote]

Waar ik vandaan kom worden bovenstaande zaken toch echt als beledigend ervaren, maar goed. Ik moet wel eerlijk toegeven dat ik hardop moest lachen toen ik zag dat je me had aangemeld bij de mods vanwege mij sig, dat vind ik echt geweldig. Dat je dat ervaart als een:

[quote]
diepe, diepe belediging, temeer omdat ik echt oprecht mijn best gedaan heb om uit te leggen wat ik vind van de bediscussieerde materie
[/quote]

En dat er dan onder die post staat "Martin Fowler is een prutser"....Echt geweldig. Dank daarvoor! Je hebt meerdere malen zelf gezegd dat je onbekend bent met het werk van Fowler, oa:

[quote]
...ik ken het boek inhoudelijk niet...
[/quote]

Maar toch durf je het aan de man een prutser te noemen op basis van 1 artikel, terwijl dat artikel juist voortkomt uit een veel bredere kijk op softwareontwikkeling (XP) waar je IMHO toch in ieder geval goed bekend mee moet zijn (door het lezen van zijn werk) voordat je hem een prutser kan en mag noemen. Ik denk eerlijk gezegd dat ik beter op de hoogte ben van jouw ideeen omtrent softwareontwikkeling dan dat jij dat bent over de ideeen van Fowler en daarom vind ik dat ik net zoveel of misschien nog wel meer recht heb jouw een prutser te noemen.... Het is mijns inziens wederom een voorbeeld van het gebrek aan nuance dat je ook tentoonspreidt bij het 'afmaken' van de DataSet zoals je dat in het begin van deze discussie gedaan hebt. En DAT is waartegen ik opkom, het enige wat ik wil is een beetje nuance in de discussie. Nu lijkt het alsof de DataSet een rechtstreekse afstammeling van Satan himself is en dat is helemaal niet zo!

[quote]
Tja. Welke posting zou dan dan moeten zijn, waar ik dingen verkondig die, wanneer toegepast in jouw ontwikkelteam, schade zouden kunnen berokkenen en je ontwikkelwerk onherstelbaar nadelig kunnen beinvloeden, Paul (Gielens)? Enig idee?
[/quote]

Ja, de posting die de DataSet op 1 zet in jouw top 10 van meest onzinnige technologieen, waardoor iemand zou kunnen besluiten deze niet te gebruiken als basis voor een DAL en waardoor ze heel erg veel tijd kwijt zijn om bijvoorbeeld zelf een heleboel zaken te bouwen die standaard in de DataSet zitten. Ik zeg niet dat ze altijd voor de DataSet moeten kiezen, maar ik sta pal achter mijn stelling dat er veel scenarios te bedenken zijn waarin de DataSet een hele hoop ontwikkelingstijd en -geld kan besparen. In die zin is jouw ongenuanceerd opstelling schadelijk en DAAROM mag ik jouw volgens mij een prutser noemen.

[quote]
....zeker als je bedenkt dat veel gebruikers van de dataset totaal niet weten wat 'stateful' inhoudt en de gevaren die dat met zich meebrengt in stateless omgevingen zoals webapplicaties....
[/quote]

Het probleem ligt dus bij de GEBRUIKERS, niet bij de DataSet, deze biedt voldoende mogelijkheden om alle door jouw genoemde problemen te ondervangen en bezit verder mijns inziens geen unieke eigenschappen vergeleken met bijv. collecties entity objecten die het rechtvaardigen de DataSet zo in het verdomhoekje te zetten als jij doet.


Om toch nog een beetje ontopic te blijven nog een reactie op whoami:

quote:

Ja maar, wat als die data ondertussen al veranderd is ? Als je je dataset in de viewstate houdt, en niet refreshed, wat dan?
Ik vind dat EfBe daar wel een punt heeft.


Tuurlijk, maar datzelfde geldt voor elke DAL die niet rechtstreeks maar mbv bijv entity objecten zijn data doorgeeft. EfBe heeft een punt, maar het is absoluut niet iets unieks voor de DataSet en het is dus ook geen rede om daarom de DataSet als 'slecht' te zien. Nogmaals: de gebruiker kan (en moet) bepalen wanneer de data opnieuw opgehaald wordt. Ik kan me bijvoorbeeld voorstellen dat het voor paging en sorting operaties zelfs verwarrend kan werken als je steeds nieuwe data uit de DB haalt, zo zou een record dat de ene keer op pagina 1 komt daarna ineens (na een hoop inserts) ook weer op pagina 3 terugkomen? Of staat er ineens een hele andere waarde bovenaan als je opnieuw sorteert. Ik zeg niet dat voorgaande altijd waar is, misschien wil je wel altijd de nieuwe waarden ophalen, maar misschien ook wel niet. De DataSet biedt de flexibiliteit die het mogelijk maakt om een keuze te maken tussen beide opties.

quote:
Hoe bieden ze daar dan bescherming tegen aan?


Het is eigenlijk doodsimpel, naast de events waar paulg al naar refereeerde wordt door de DataAdapter een UPDATE statement niet eenvoudige zo geschreven:


code:
1
UPDATE bla bla bla WHERE pk=x;



maar zo:


code:
1
UPDATE bla bla bla WHERE c1=oudewaarde, c2=oudewaarde c3=oudewaarde enz enz enz.



Als de data dus inmiddels verandert is wordt de update niet doorgevoert. De DataAdapter checkt hoeveel rijen er aangepast zijn door de UPDATE en als dat er minder zijn dan verwacht gooit hij een DBConcurrencyException op. Je hoeft hier geen enkele extra regel code voor te schrijven en in die zin is dat dus een groot voordeel boven de eenvoudige UPDATE die de meeste mensen (vanwege tijdsdruk of gewoon omdat ze niet beter weten) zelf schrijven.

quote:
Daarnet zei je nog dat je de DataSet in je viewstate hield, om zo bij een postback minder queries te moeten doen op je DB.


Als ik daarvoor kies wel, als ik het anders wil dan kan het. De DataSet biedt me opties, als ik ervoor kies die te misbruiken, 'so be it', misschien heb ik daar zelfs wel een goede reden voor.

Het feit dat technologieen als ObjectSpaces kiezen voor DataSets als basis en dat, zoals al eerder genoemd is, er sterke indicaties zijn dat MSFT gewoon de DataSet richting op blijft gaan moeten toch een indicatie zijn dat het ding zo slecht nog niet is. Ze zijn bij MSFT echt niet achterlijk! Er zitten daar een hele hoop hele slimme mensen die heel goed weten waar ze mee bezig zijn.

whoami wijzigde deze reactie 20-04-2003 15:50 (1%)

EfBe is geweldig !


  • drm
  • Registratie: februari 2001
  • Laatst online: 02-11 11:58

drm

f0pc0dert


adminbreak
Ik stel voor dat we hier kappen met flamerig en trollerig gedrag. Back ontopic, en kappen met die ellenlange offtopic replies.

paullooijmans, check je mail.


Music is the pleasure the human mind experiences from counting without being aware that it is counting
~ Gottfried Leibniz
[ melp.nl | twitter ]


  • EfBe
  • Registratie: januari 2000
  • Niet online
quote:
maikel schreef op 20 April 2003 @ 13:13:
De reden dat deze discussie zo hoog oploopt is dan ook niet dat je onzin zou uitkramen, maar je uitspraken als "DataSets zijn het domste dat ooit gebouwd is" en "MS is totaal de weg" kwijt: deze zijn nogal zwart/wit.

Ik heb niet gezegd dat datasets het domste dat ooit gebouwd is. Ik heb aangegeven dat het een concept is dat serieuze flaws heeft bij multi-user gebruik en daardoor niet slim is om te gebruiken in dat soort omgevingen. Als MS dan toch daarop doorgaat vind ik dat je op dat gebied de weg behoorlijk kwijt bent. En dat mag dan zwart/wit zijn, ik vind dat. Er worden mij nu woorden in de mond gelegd / uitspraken aangewreven die ik nooit gezegd heb/gedaan heb. Quote het bericht maar waar ik dat zeg wat jij beweert, dat ik het een van de domste technologieen ooit heb genoemd. (ik kon 'domste' alleen terugvinden in een posting van paul)

(edit) ah ik zag dit van mezelf staan:
"datasets zijn pure overkill, en nog net niet zo onnozel als datareaders, maar ze schurken wel tegen elkaar aan om de eerste plek in de top 10 aller tijden der onbenullige technologieen. ;) ". Die smiley staat er niet voor niets, m.a.w: aanduiding van een overstated statement.

quote:
Paul geeft aan dat er scenario's te bedenken zijn waarin DataSets juist wel handig kunnen zijn, in de hoop dat jij je mening enigszins nuanceert. Maar je blijft toch volhouden dat DataSets en DataReaders allebei slecht/evil zijn.

Ho ho, ik heb OOK aangegeven dat er scenario's zijn dat de dataset juist wel handig is, in deze thread zelfs MEERDERE malen. Namelijk in single user omgevingen, daar waar je de enige user bent in de applicatie en DUS het volgende waar is: "application state in user process == application state".

In Multi-user omgevingen is dit TOTAAL anders. Omdat je, wanneer je daar NIET van doordrongen bent, een erg lelijke val kunt maken, is de dataset een 'evil' object, in die zin, dat je er terdege van bewust moet zijn waar je mee bezig bent, en MS doet er iig NIETS aan om dat duidelijk te maken.

Dit heb ik meerdere malen zo verwoord, ik zie niet in waarom ik NOG genuanceerder moet zijn. Het meningsverschil gaat er dan ook om dat in de MULTI-useromgevingen datasets wel degelijk nuttig kunnen zijn, en dat zie ik niet zo, omdat je dubbel werk doet en veel risico loopt dat je dingen moet terugdraaien in je dataset, enfin dingen die ik al heb aangegeven.
quote:
Ik ben van mening dat zowel jij als Paul allebei goed weten waar jullie het over hebben en ga er dus vanuit dat jullie kennis hier op GoT erg gewaardeerd wordt.

Waarom zou je de kennis van mij, een prutser, willen waarderen? Het meningsverschil is fundamenteel, echt een 'tot op het bot verdeeld' gezelschap zeg maar.

Over nuance: ik weet echt wel wat dat is, en ik weet ook wanneer ik het weglaat en dat dat op sommige momenten door sommige mensen niet aardig wordt gevonden. Ik heb, en dat moet je van me aannemen, juist nuance getracht toe te voegen aan mijn stelling, omdat ik weet dat deze zwart/wit overkomt en daarom heb ik ook geprobeerd twee dingen aan te geven:

1) DataSets zijn in single user winform programma's erg handig, en niet schadelijk, immers je werkt single user, dus het stateless/stateful verhaal is niet ter zake doende
2) Mits je ERG GOED weet waar je mee bezig bent (lees: erg veel weet van stateless applicaties zoals websites en de daarin embedded enterprise applicaties) de dataset niet zo evil hoeft te zijn, het levert alleen extra werk op. Erg veel developers voldoen echter niet aan deze criteria maar werken juist WEL met de dataset (en waar je door de wol geverfde developers ziet werken met andere mechanismen dan de dataset).

NOG meer nuance lijkt me niet ter zake doende, temeer omdat de stelling met deze 2 nuanceringen (die ik meerdere keren heb verwoord) een nauwer toepassingsgebied heeft dan 100% van de applicaties EN ontwerpkeuzes.

Tegen paul looijmans zou ik willen zeggen dat als hij zich aangevallen voelt door mij omdat ik stellingen opper die zijn ontwerpbeslissingen in een ander daglicht stellen, hij dat niet zo moet opvatten. Als hij vindt dat DataReader objects geweldig zijn en hem veel helpen, en ik roep dat het evil objects zijn (wat ik ook genuanceerd heb in deze thread btw) en hij dan denkt: "die eikel vindt dat ik dus evil objects gebruik en DUS dom bezig ben", hij dan de discussies hier verkeerd opvat. Wellicht zijn er andere criteria, buiten beschouwing gelaten van de huidige discussie die WEL van toepassing zijn op hetgeen hij aan werkt en DUS dat een keuze voor bv een DataReader wel nuttig kan zijn. Ik snap ook wel dat als je een O/R mapper maakt en je in 1 class een table uitleest en die meteen in een objectlist propt (dus 1 row is 1 object), je niet eerst die results in een datatable gaat plaatsen, die dan weer uit gaat lezen in je objects. M.a.w.: de situatie waarover je DAN praat is een hele andere dan wanneer je bv praat over een datareader openen in een DAL en die aan een repeater control plakken in een asp.net layer, de situatie waar mijn Datareader stelling over ging.

Als Paul na dit gelezen te hebben nog denkt dat ik een prutser ben omdat ik kennelijk dingen verkeerd beoordeel, dan is dat dan jammer. De IT is vergeven van prutsers die die dezelfde IT ten gronde richten en daar toe gerekend worden door personen is in mijn ogen een zeer vervelend iets. Maar goed, c'est la vie zullen we maar zeggen. (en dat Fowler== een prutser hieronder staat, vind ik dan ook oprecht, ongeacht zn wellicht goede werk op het gebied van XP en Patterns.)

EfBe wijzigde deze reactie 21-04-2003 10:44 (9%)

Lead developer of LLBLGen Pro, the productive O/R mapper for .NET
My .NET Blog | Twitter


  • paullooijmans
  • Registratie: februari 2003
  • Laatst online: 08-02-2007
quote:
Tegen paul looijmans zou ik willen zeggen dat als hij zich aangevallen voelt door mij omdat ik stellingen opper die zijn ontwerpbeslissingen in een ander daglicht stellen, hij dat niet zo moet opvatten.


Ik verwelkom iedere stelling die mijn ontwerpbeslissingen in een ander daglicht stellen met open armen. Discussies als deze, op het scherpst van de snede, dwingen ons beide onze argumenten goed te analyseren en helder neer te zetten, in die zin zijn we dan ook beide beter geworden van deze discussie.

quote:
Als Paul na dit gelezen te hebben nog denkt dat ik een prutser ben omdat ik kennelijk dingen verkeerd beoordeel, dan is dat dan jammer.


Ik heb helemaal nooit gedacht dat je een prutser bent. Koppig ja, ongenuanceerd soms, maar daar is niets mis mee want dat ben ik ook. Zoals ik in mijn (blijkbaar te lange) offtopic reply al gezegd heb waren mijn post en mijn sig een parodie op de toon/discussiestijl die jij nogal eens gebruikt om je argumenten kracht bij te zetten, algemeen bekend onder de noemer 'Ad Hominem', ofwel 'op de man'. Ik heb daar in mijn offtopic enkele voorbeelden van genoemd. Ik doe dit overigens niet om je 'in de zeik te nemen' oid, ik wil er alleen duidelijk mee maken dat je manier van uiten soms nogal denigrerend overkomt. Je weet dat er op dit forum veel mensen zitten die Fowler 'op handen dragen' en als jij inderdaad zo beledigd bent door mijn sig, stel je dan eens voor wat voor effect jouw sig KAN hebben.

quote:
en dat Fowler== een prutser hieronder staat, vind ik dan ook oprecht, ongeacht zn wellicht goede werk op het gebied van XP en Patterns.


Je moet het met me eens zijn dat je de stelling 'X is een prutser' niet kunt baseren op een enkel artikel omdat het, zoals ik al zei, ingebed is in een veel bredere kijk op softwareontwikkeling waar jij naar eigen zeggen (net zo min als ik overigens) niet mee bekend bent.

Ik zou het dan ook erg op prijs stellen als je je sig aanpast. Overigens vind ik de toon in je laatste post een gigantische verbetering! Als reactie daarop heb ik mijn sig nog maar eens aangepast, hope you like it !

quote:
Waarom zou je de kennis van mij, een prutser, willen waarderen? Het meningsverschil is fundamenteel, echt een 'tot op het bot verdeeld' gezelschap zeg maar.
Wij weten allebei wel beter. Ik ga geen tijd verspillen aan het reageren op reacties van (in mijn ogen) prutsers, jij ook niet neem ik aan. Het feit dat we de tijd nemen om diepgaand op elkaars posts in te gaan zegt mijns inziens genoeg, ik hoop dan ook in de toekomst nogmaal de degens met je te mogen kruisen!

EfBe is geweldig !


  • EfBe
  • Registratie: januari 2000
  • Niet online
quote:
paullooijmans schreef op 21 April 2003 @ 12:05:
Ik verwelkom iedere stelling die mijn ontwerpbeslissingen in een ander daglicht stellen met open armen. Discussies als deze, op het scherpst van de snede, dwingen ons beide onze argumenten goed te analyseren en helder neer te zetten, in die zin zijn we dan ook beide beter geworden van deze discussie.

Ok.

quote:
Ik heb helemaal nooit gedacht dat je een prutser bent. Koppig ja, ongenuanceerd soms, maar daar is niets mis mee want dat ben ik ook. Zoals ik in mijn (blijkbaar te lange) offtopic reply al gezegd heb waren mijn post en mijn sig een parodie op de toon/discussiestijl die jij nogal eens gebruikt om je argumenten kracht bij te zetten, algemeen bekend onder de noemer 'Ad Hominem', ofwel 'op de man'.

Met het risico opnieuw in een felle strijd te belanden, mag ik een klein puntje aangeven? Als je de thread nu nog eens van boven naar beneden doorleest, en je belandt op een gegeven moment aan bij je eigen 1e posting in deze thread, vind je dan ook niet dat die wel erg driest begint? Ik heb juist geprobeerd zoveel mogelijk op de man-gezever te vermijden (je moest eens weten wat ik heb verwijderd uit die lange posting ;) ) maar sommige dingen heb ik laten staan, ik vind dat ook niet vreemd na geconfronteerd te worden met jouw openingszinnen, maar goed, ik hoop dat je ook inziet dat dat soort openingen van postings degene waarop je reageert wellicht niet al te blij maken, om het maar zo uit te drukken ;)

quote:
Ik heb daar in mijn offtopic enkele voorbeelden van genoemd. Ik doe dit overigens niet om je 'in de zeik te nemen' oid, ik wil er alleen duidelijk mee maken dat je manier van uiten soms nogal denigrerend overkomt. Je weet dat er op dit forum veel mensen zitten die Fowler 'op handen dragen' en als jij inderdaad zo beledigd bent door mijn sig, stel je dan eens voor wat voor effect jouw sig KAN hebben.

Ben ik me ook van bewust, juist daarom staat die sig er. Ik weet niet hoevaak je hier leest, maar ik werd er op een gegeven moment een beetje moe van om telkens met Fowler dit en Fowler dat te worden geconfronteerd, dus ik dacht, ik ga de beste man's website eens doornemen. Helaas voor Fowler trok zijn evolutionairy database verhaal meteen de aandacht. Ik had net een project achter de rug waarbij ik als externe bij een groepje knutselaars was gehaald om iets te bouwen en belandde in een omgeving die precies werkte zoals in dat artikel was omschreven (en als je je iets kunt voorstellen hoe iets fout kan gaan in ontwikkeltrajecten, vermenigvuldig dat met 10 en je hebt ong. een beeld) dus ik had echt zoiets van: die meneer is helemaal niet zo geweldig, integendeel, he has to be stopped! ;). Als je dat brengt met een harsh statement, valt het op, leest men het en gaat men wellicht daarover nadenken. Wat exact de bedoeling is. Maar ik wil hem best aanpassen hoor, is "Fowler snapt helaas niets van abstract database modelling" iets?

quote:
Je moet het met me eens zijn dat je de stelling 'X is een prutser' niet kunt baseren op een enkel artikel omdat het, zoals ik al zei, ingebed is in een veel bredere kijk op softwareontwikkeling waar jij naar eigen zeggen (net zo min als ik overigens) niet mee bekend bent.

Welke bredere kijk bedoel je precies, want ik had de indruk dat ik wel degelijk begreep waar Fowler in dat artikel op doelde. Ik snap ook best de beweegredenen wel, er wordt echter voorbijgegaan aan de gevaren van het gepredikte, en juist dat mag na al die jaren van mislukte automatiseringsprojecten in de IT wel eens op de voorgrond worden geplaatst. Als je eXtreme Programming all-the-way accepteert als de ontwikkelmethodiek waar je als team je software mee gaat bouwen, dan is het artikel logisch. Dat maakt het echter niet minder gevaarlijk.

quote:
Ik zou het dan ook erg op prijs stellen als je je sig aanpast. Overigens vind ik de toon in je laatste post een gigantische verbetering! Als reactie daarop heb ik mijn sig nog maar eens aangepast, hope you like it !

heh :) Zo geweldig heb ik niet hoor. :) Je moest eens weten wat voor code ik per dag wegflikker. (zit bv al 2 weken te prutsen met een SQL Expression editor die geen syntaxchecking nodig heeft (visual designer) maar ik krijg het maar niet voormekaar)

quote:
Wij weten allebei wel beter. Ik ga geen tijd verspillen aan het reageren op reacties van (in mijn ogen) prutsers, jij ook niet neem ik aan. Het feit dat we de tijd nemen om diepgaand op elkaars posts in te gaan zegt mijns inziens genoeg, ik hoop dan ook in de toekomst nogmaal de degens met je te mogen kruisen!
Ik hoop het ook, en dan hoop ik ook dat je je niet op de kast laat jagen door mijn soms zwart/wit verwoorde stellingen, veelal gelden die niet overal, en dat laatste is juist erg belangrijk.

Lead developer of LLBLGen Pro, the productive O/R mapper for .NET
My .NET Blog | Twitter


  • whoami
  • Registratie: december 2000
  • Laatst online: 08:07
In het 3de nummer van het .NET magazine van Microsoft is er een artikel gewijd aan de problematiek van het persisten van DataSets en concurrency problemen in applicaties.

Straks ff lezen.

DevLog - FotoLog


  • EfBe
  • Registratie: januari 2000
  • Niet online
Hmm, overheen gelezen. Ik had dat 3e nummer sneller uit dan de computable, en dat is niet een positieve opmerking ;) (ergo: ik vond er niet veel interessants in staan, wat nieuw was.) De code die ik hier en daar zag was ook erbarmelijk, het wordt meer en meer een marketing blaadje voor bedrijven om zich via de artikelen van werknemers te profileren. Wel jammer, want het 1e nummer was wel erg goed.

EfBe wijzigde deze reactie 04-05-2003 21:07 (56%)

Lead developer of LLBLGen Pro, the productive O/R mapper for .NET
My .NET Blog | Twitter

Pagina: 1


Populair:Apple iPhone 6Samsung Galaxy Note 4Apple iPad Air 2FIFA 15Motorola Nexus 6Call of Duty: Advanced WarfareApple WatchWorld of Warcraft: Warlords of Draenor, PC (Windows)Microsoft Xbox One 500GBTablets

© 1998 - 2014 Tweakers.net B.V. Tweakers is onderdeel van De Persgroep en partner van Computable, Autotrack en Carsom.nl Hosting door True

Beste nieuwssite en prijsvergelijker van het jaar 2013