[delphi/disc] MVC Realiseren

[Verwijderd]

Ik programmeer al een tijdje in delphi, maar dat was van het niveau van een peuter.

Na les gehad te hebben in UML, java, etc, probeer ik het ook in andere omgevingen te realiseren / implementeren.

In java is het implementeren van het MVC-principe te doen (lees: het bedenken en vast houden van het idee is wel moeilijk, maar als dat gaat, is het implementeren te doen).

Nu is mijn punt: 'Hoe kan je het succesvol in Delphi implementeren?'.

Zijn er mensen die (serieuse) succesvolle pogingen hebben gedaan, oid?
_{ik mag toch hopen van wel...}

edit:

Google, en got leverden bedroevend weinig nuttige info.

[ Voor 7% gewijzigd door Verwijderd op 07-05-2003 21:55 ]

[Verwijderd]

/me schopt

[Delphi32]

In zekere zin beschikt de library waarmee ik dagelijks werk over een MVC-implementatie (laat ik even in het midden of die volledig voldoet aan de 'eisen'). Dus ja het kan wel. Tuurlijk; Delphi laat je in principe vrij om te bouwen wat jij mooi vindt
De objecten waarmee we werken, hebben allemaal overal en nergens zogenaamde event handler lists. Waar je normaal 1 event handler aan de OnClick van een TButton kan hangen, kan je nou op een TCustomer een hele serie van handlers hangen. Wijzigt er iets in de TCustomer instantie, dan worden alle geabboneerden op de hoogte gesteld middels de event handler list.
Ik ben daar persoonlijk niet zo blij mee. Keer op keer is gebleken dat er in de handlers allerlei zaken geregeld worden die nare gevolgen hebben. De volgende issues doen zich voor:
1. de handler wijzigt iets aan de TCustomer instantie waardoor weer een hele serie event handlers afgewerkt wordt, met mogelijk recursie als gevolg, of erger.
2. het is een crime om de event handlers te debuggen. Omdat je niet weet welke event handlers zich geregistreerd hebben moet je (in een complex project als het onze) maar afwachten of Delphi in staat is om alle handlers correct te tracen. Soms helpt alleen een grep door de 1 miljoen regels code. Is niet leuk, je bent veel te lang bezig om te zoeken waar een probleem zich voordoet.

Nu zou je kunnen tegenwerpen dat dat grotendeels de schuld is van programmeurs die het concept niet begrijpen, maar ik vind dat nog steeds een zwaktebod. Programmeurs zijn mensen (hoop ik ), mensen maken fouten. Op implementatie-vlak (dan heb je een bug) of op concept-niveau (misbruik van de handlers). Voeg beide samen en je hebt een kleine ramp. Liever zie ik een concept dat deze problemen zoveel mogelijk voorkomt.

Tot zover mijn ervaringen met MVC, niet erg positief dus. Maar ik hoop dat er nu wat meer (positievere?) reacties komen

[Alarmnummer]

Je kan het in Delphi zeker doen, maar ik denk dat je wel redelijk wat grondwerk moet gaan verrichten. Je zult ten 1e moeten gaan werken aan speciale viewmodels. In java zijn dit de TableModel, ComboboxMode, Document ed. Als onderdeel van deze view models zul je dus ook event-support moeten bouwen. Tenslotte moet een view-model een event naar de view kunnen afgeven als daar iets is veranderd. En vanuit de view moet je een event naar de view-model kunnen doorgeven.

Zo gauw je deze viewmodels klaar hebt kun je beginnen met je eigen models aan te sluiten op de view-models mbv observer/observable design pattern.

[Alarmnummer]

Delphi32 schreef op 09 May 2003 @ 00:18:
In zekere zin beschikt de library waarmee ik dagelijks werk over een MVC-implementatie (laat ik even in het midden of die volledig voldoet aan de 'eisen'). Dus ja het kan wel. Tuurlijk; Delphi laat je in principe vrij om te bouwen wat jij mooi vindt
De objecten waarmee we werken, hebben allemaal overal en nergens zogenaamde event handler lists. Waar je normaal 1 event handler aan de OnClick van een TButton kan hangen, kan je nou op een TCustomer een hele serie van handlers hangen. Wijzigt er iets in de TCustomer instantie, dan worden alle geabboneerden op de hoogte gesteld middels de event handler list.
Ik ben daar persoonlijk niet zo blij mee. Keer op keer is gebleken dat er in de handlers allerlei zaken geregeld worden die nare gevolgen hebben. De volgende issues doen zich voor:
1. de handler wijzigt iets aan de TCustomer instantie waardoor weer een hele serie event handlers afgewerkt wordt, met mogelijk recursie als gevolg, of erger.
2. het is een crime om de event handlers te debuggen. Omdat je niet weet welke event handlers zich geregistreerd hebben moet je (in een complex project als het onze) maar afwachten of Delphi in staat is om alle handlers correct te tracen. Soms helpt alleen een grep door de 1 miljoen regels code. Is niet leuk, je bent veel te lang bezig om te zoeken waar een probleem zich voordoet.

Nu zou je kunnen tegenwerpen dat dat grotendeels de schuld is van programmeurs die het concept niet begrijpen, maar ik vind dat nog steeds een zwaktebod. Programmeurs zijn mensen (hoop ik ), mensen maken fouten. Op implementatie-vlak (dan heb je een bug) of op concept-niveau (misbruik van de handlers). Voeg beide samen en je hebt een kleine ramp. Liever zie ik een concept dat deze problemen zoveel mogelijk voorkomt.

Tot zover mijn ervaringen met MVC, niet erg positief dus. Maar ik hoop dat er nu wat meer (positievere?) reacties komen

Als ik een gui ontwerp dan zet ik het altijd mbv MVC op. Hoe het luisteren dan voor elkaar gaat krijgen in een 2e, maar daar kan je mvc niet op afrekenen. Ik heb er zelf eerlijk gezegd weinig problemen mee gehad, maar java is het ook een stuk eenvoudiger om gestructureerde code af te leveren dan in Delphi.

[Verwijderd]

Alarmnummer schreef op 09 May 2003 @ 12:22:
Je kan het in Delphi zeker doen, maar ik denk dat je wel redelijk wat grondwerk moet gaan verrichten. Je zult ten 1e moeten gaan werken aan speciale viewmodels. In java zijn dit de TableModel, ComboboxMode, Document ed. Als onderdeel van deze view models zul je dus ook event-support moeten bouwen. Tenslotte moet een view-model een event naar de view kunnen afgeven als daar iets is veranderd. En vanuit de view moet je een event naar de view-model kunnen doorgeven.

Zo gauw je deze viewmodels klaar hebt kun je beginnen met je eigen models aan te sluiten op de view-models mbv observer/observable design pattern.

Hmm, tijd om dit idee eens in uml/delphi code om te zetten .