[vb .net] Gui scheiden van app-logic door events?

Pagina: 1
Acties:

  • Rodyman
  • Registratie: November 2001
  • Laatst online: 08-06-2024
Voor een oefening in vb .net ben ik een black-jack spel aan het nabootsen. Hierbij wil ik de GUI zo veel mogelijk gescheiden houden van de applicatie zelf.

Nu zit ik me af te vragen hoe ik dit het beste kan doen. Ik heb een klasse 'Spel' die het verloop van het spel helemaal regelt, wie er wanneer een kaart moet pakken e.d.
Is het nu een goed idee om wanneer de bank bijvoorbeeld een kaart pakt, een event te raisen zodat de gui kan zien dat de bank een kaart gepakt heeft? zodat als ik later een andere GUI eraan wil hangen, alleen deze events hoef af te vangen.

Of is dit geen goede manier van het scheiden van een GUI en de applicatie logica? Hoe zou ik dit dan anders moeten aanpakken?

  • NMe
  • Registratie: Februari 2004
  • Laatst online: 15-04 22:07

NMe

Quia Ego Sic Dico.

Zoek eens naar het observer design pattern. :)

'E's fighting in there!' he stuttered, grabbing the captain's arm.
'All by himself?' said the captain.
'No, with everyone!' shouted Nobby, hopping from one foot to the other.


  • Woy
  • Registratie: April 2000
  • Niet online

Woy

Moderator Devschuur®
of specifiek voor GUI's MVC ( Model View Controller als ik me niet vergis )

“Build a man a fire, and he'll be warm for a day. Set a man on fire, and he'll be warm for the rest of his life.”


  • whoami
  • Registratie: December 2000
  • Laatst online: 02-05 14:39
Rodyman schreef op zondag 14 augustus 2005 @ 20:03:
Is het nu een goed idee om wanneer de bank bijvoorbeeld een kaart pakt, een event te raisen zodat de gui kan zien dat de bank een kaart gepakt heeft? zodat als ik later een andere GUI eraan wil hangen, alleen deze events hoef af te vangen.

Of is dit geen goede manier van het scheiden van een GUI en de applicatie logica? Hoe zou ik dit dan anders moeten aanpakken?
Dat is een manier om het te doen; je kunt een DLL maken, met een aantal klassen die de eigenlijke logica van je applicatie bevat. Die classes kunnen idd een aantal events hebben die getriggered worden door die classes.
Dan kan je idd een GUI applicatie maken waarin je die DLL gebruikt, de classes ervan gebruikt, members oproepen, event-handlers aan de events hangen, etc...

https://fgheysels.github.io/


  • Rodyman
  • Registratie: November 2001
  • Laatst online: 08-06-2024
Bedankt voor de tips! Nu jullie het noemen, komt me weer vanalles boven wat ik heb geleerd op school :)
Het observer pattern was precies wat ik zocht.

Voor mensen die hier meer informatie willen hebben over deze design patterns icm het .net framework, kijk eens hier:
http://msdn.microsoft.com.../html/observerpattern.asp
Dat vond ik een fijne beschrijving van het eea.

  • Rodyman
  • Registratie: November 2001
  • Laatst online: 08-06-2024
Ok ik werk nu volgens de manier met de events en delegates van:
http://msdn.microsoft.com.../html/observerpattern.asp
Maar nu lijkt me dit toch maar 1 kant op te werken? Namelijk als de app.logica een wijziging wil maken aan de GUI.

Maar de andere kant op, als de gebruiker een actie uitvoerd, bijvoorbeeld op een button drukt, heb ik niets aan deze methode ofwel?

Moet ik dit dan toch ook nog met een soort van MVC structuur toepassen om het netjes gescheiden te krijgen?

  • Woy
  • Registratie: April 2000
  • Niet online

Woy

Moderator Devschuur®
Je moet het simpel gezegd zo zien je hebt een Observer( Je gui ) en een Observable( een domein object ) een observer zegt tegen een observable dat hij op de hoogte gehouden wil worden van wijzigingen. Er kunnen meerdere Observers aangemeld zijn bij een Observable.

Als er dus iets gewijzigd wordt aan een Observable dan worden alle Observers ingelicht. Zo haalt het dus niet uit waarvandaan je iets aan je object veranderd. Alle Gui onderdelen die zich aangemeld hebber krijgen daar bericht van. De andere kant haalt niet zoveel uit. Als er iets op een Interface component gebeurt hoeven niet alle domein objecten dat te weten. Alleen iedereen die zich bij het Observable object aangemeld hadden. En dat gebeurt dus weer als een interface component een wijziging maakt.

Het MVC patern is wel weer iets anders

“Build a man a fire, and he'll be warm for a day. Set a man on fire, and he'll be warm for the rest of his life.”

Pagina: 1