Archief - [Java] "Stijlvol" model-view-controller implementeren

Hallo,
Ik vroeg me af wat de meest elegante manier is om een applicatie te schrijven volgens het MVC principe.
Mijn prof programmeren (K. Coolsaet) drukte vorig jaar enorm hard op stijl en herbruikbaarheid, vandaar deze vraag. Ook omdat ik me afvraag wat het meeste gedaan wordt.

Bon, stel dat je een applicatie schrijft met een GUI, bestaande uit verschillende onderdelen. Die verschillende onderdelen hangen deels aan elkaar vast in die zin dat een verandering van onderdeel x ook een verandering in onderdeel y teweeg brengt.
Mijn vraag nu: hoe wordt dit het meeste/meest stijlvol/meest herbruikbaar/... aangepakt.

A) Je groepeert view en controller (hetgeen men ook een "interface" noemt) en laat deze met de nodige modellen communiceren.
Voordelen: je kan elk onderdeel van je applicatie in een aparte package steken. Dit zorgt er voor dat je, wanneer je dit onderdeel ooit in een andere applicatie nodig hebt, je gewoon de package kan importeren et voila.
Nadeel: het kan voorkomen dat je constructoren krijgt met bij wijze van spreken 10 argumenten, omdat bepaalde onderdelen informatie nodig hebben uit zeer veel modellen. Soms kan het ook voorkomen dat je modellen langs 5 klassen moet doorgeven eer ze hun doel bereiken.
=> zeer herbruikbaar en matig uitbreidbaar.

B) Je hebt een hele groep modellen en per onderdeel een view. Je schrijft echter 1 overkoeplende controller voor heel je applicatie.
Voordeel: Elke view registreer je bij de overkoepelende controller, die macht heeft over elk model. Op die manier heeft elke view onmiddellijk toegang tot elk model. Constructoren worden eenvoudiger en je moet de modellen ook niet nodeloos "doorgeven".
Nadeel: Wanneer je een onderdeel wil hergebruiken in een andere applicatie, dan kan je enkel de view recupereren. Al de rest moet je herschrijven.
Nieuwe views toevoegen gaat echter vlot: ze krijgen al hun informatie eenvoudig via de controller.
=> zeer uitbreidbaar, geen overbodige argumenten in constructoren

C) Is er een andere, professionelere manier?

Alvast bedankt voor jullie hulp!

hey,

eerst en vooral moet ik zeggen dat ik absoluut geen ervaring heb met java, dus ik weet niet zeker hoe het daar zit.

ikzelf heb al met twee verschillende "versies" van het MVC-pattern gewerkt. Ik denk dat het goed is om mijn visie te geven over de verschillende onderdelen binnen MVC.

Model: Model is dat deel van de applicatie dat de betekenis geeft aan de data. Het is datgene wat zorgt dat de data consistent is door het implementeren van regels die voor de data moet gelden. Wat het model aanbiedt zou theoretisch gezien volledig vervangbaar moeten zijn door een model dat zijn data van een andere plek haalt (andere db bv)

View: het deel van de applicatie dat zorgt voor het weergeven van de aangeleverde informatie (!= data)

controller: dit deel verzorgt de transformatie van de data in informatie die bruikbaar is om weer te geven. het is ook in de logica van de controller dat bewerkingen op data gebeurd.

een belangrijk deel van deze uitleg is de vervangbaarheid van de drie delen. elk deel staat volledig op zichzelf en moet in theorie volledig vervangbaar zijn.

Om op uw vraag terug te komen ben ikzelf voorstander van 2 concrete implementaties:
ASP.NET MVC: deze implementatie gebruikt een controller per logische eenheid binnen de applicatie. Alle logica staat zo voor een bepaald onderdeel bij elkaar. vooral voor het bouwen van websites is dit goed bruikbaar, omdat de interactie met de gebruiker niet overvloedig aanwezig is.
1 controller per view: Deze implementatie geniet mijn voorkeur bij het maken van echte applicaties. Een concreet voorbeeld hiervan is vidyano. de reden waarom dit mijn voorkeur geniet bij gewone windows applicaties is omdat de interactie met de gebruiker veel groter is dan bij een website. Als je alle logica dan in 1 controller moet steken, wordt deze zo groot dat hij niet meer handelbaar is. 1 controller per view is dan echt wel handig als je een grotere applicatie wil bouwen.

Ik mis het Observer pattern in beide uitleggen.

View = alle schermen. Hier mag niets van data of logica in zitten.
Model = alle data en alle logica.
Controller = Regelt de toegang tot het model. Zorgt voor de vertaalslag van GUI acties naar model functionaliteit.

Volgens mij is de meest strikte implementatie van het MVC pattern dit:
- De controller(s) is de listener voor alle GUI events. De controller zou dus de actionlistener, listselectionlistener, en wat hebt ge daar allemaal, moeten zijn van elk GUI component.
- De controller laat het model doen wat het moet doen. De controller kent dus het model.
- Het model vuurt vanzodra er iets gewijzigd is, update notifications uit naar wie ook geïnteresseerd is. Het model is dus "observable".
- Die geïnteresseerden zijn dan GUI componenten... Die zijn "observer".

Dus:
GUI => Actie => Controller => Model => GUI.

Uiteraard heb je dichterlijke vrijheid in je implementatie.
Ik hou men listeners gewoon bij de gui componenten waarvoor ze belangrijk zijn, en roep van daaruit men controller aan. Die stuurt dan al dan gegevens door naar de juiste plaats in model.
Het model wijzigt, en roept van elke observer die staat geregistreerd in het model, de update methode aan met de nodige data, zodat de observers zichzelf kunnen aanpassen aan de nieuwste data het model.

Zo kan je zomaar een nieuwe view op je model smijten, zolang die maar geregistreerd staat als observer in dat model. Of je kan er tegelijk 2 views opsmijten. 1 tabel-view en 1 grafiek-view bijvoorbeeld.
Je view kent je model ook niet rechtstreeks, zodat je model volledig overhoop mag gegooid worden zonder dat je je view hoeft aan te passen.
Omgekeerd kent ook je model je view niet rechtstreeks. Die kent enkel lijsten met "observers".
Het enige wat mee zal moeten wijzigen met je view of je model, en waarvan je er meerdere kan hebben afhankelijk van het aantal views en modellen, zijn je controllers.

Geen idee of dit de goede interpretatie is. Heb altijd al over de juiste MVC implementatie getwijfeld, maar dit is dus hoe ik het doe.

-P|b-SqUeaLeR zei:

Je view kent je model ook niet rechtstreeks, zodat je model volledig overhoop mag gegooid worden zonder dat je je view hoeft aan te passen.

Klik om te vergroten...

Binnen de grenzen van de interface van je model dan wel. Dat vind ik persoonlijk één van de verwarrendste zaken van MVC: uiteindelijk moet je view je model nog altijd redelijk goed kennen. Je kan dat dan wel oplossen met adapters, I guess, ik ben ook geen expert in MVC.

Is er iemand al in geslaagd om MVC toe te passen in games? Op de één of andere manier moet je model toch weet hebben van de animaties in je view. Neem een doordeweeks platformspel: je drukt op een knop en het ventje op het scherm slaat met zijn zwaard. Als er een vijand in de buurt is, wordt hij geraakt door het zwaard; niet onmiddelllijk, maar pakweg in de helft van de sla-met-zwaard-animatie. Hoe weet je model wanneer de view in de helft van de animatie zit?

MVC zou in dit geval handig zijn om vlotjes van grafische engines te wisselen.

Ik denk dat MVC in games niet zo goed zal lukken omdat het geen event-driven applications zijn. Een spel draait constant aan xx fps (wat betekent dat elke seconde xx keer een update() methode wordt uitgevoerd die je objecten op je scherm update en dan daarna een draw() methode uitvoerd die alles hertekend)

Wel, dan komt het toch overeen? De gameloop is de controller, de objecten het model and dat model waarschuwt de view als er veranderingen zijn en er hertekend moet worden.

forloRn_ zei:

Is er iemand al in geslaagd om MVC toe te passen in games?

Klik om te vergroten...

MVC past heel goed binnen games, zelf heb ik het al toegepast op Rabbit Wars en Mystic Mine. Zie artikel 'Model-View-Controller for games' van hoe ik dit concreet implementeer.

forloRn_ zei:

Op de één of andere manier moet je model toch weet hebben van de animaties in je view. Neem een doordeweeks platformspel: je drukt op een knop en het ventje op het scherm slaat met zijn zwaard. Als er een vijand in de buurt is, wordt hij geraakt door het zwaard; niet onmiddelllijk, maar pakweg in de helft van de sla-met-zwaard-animatie. Hoe weet je model wanneer de view in de helft van de animatie zit?

Klik om te vergroten...

In het geval dat je nu beschrijft, of wanneer je met pixel-collisions wil werken, is het inderdaad zo dat je model afhankelijk wordt van je view. Zelf probeer ik de gameplay zo op te bouwen dat dit niet niet nodig is, waardoor MVC een goeie keuze is. Maar in het andere geval moet je ermee kunnen leven dat je geen zuivere MVC meer hebt, of moet je MVC gewoon laten vallen. Het basisidee achter MVC voor games is dat je model onafhankelijk is van hoe je alles op het scherm zet.

Tiens tiens, ben jij dat? Ik was in het verleden al eens op je site terechtgekomen toen ik googlede naar "game loop."

Als ik wat meer tijd heb, zal ik dat artikel in ieder geval eens bekijken.