MVC Workshop: Een controller ontwerpen

"Wie een MVC controller ontwerpt, begint door simpel te denken."
                                                                                                  — Sam Rain

Wie een software oplossing wilt ontwerpen, zal vaak de voorkeur hebben aan de MVC strategie: Model-View-Controller ontwerpen zijn populair omdat ze structuur geven aan een applicatie. De 'C' uit MVC staat voor controller — het deel van een oplossing dat verantwoordelijk is voor de communicatie en de verwerking van informatie van en naar de applicatie. In dit artikel leggen we de loep over het ontwerpen van een 'controller'.

Applicaties hebben meerdere models, views en dus ook controllers. Iedere 'feature' werkt op zijn eigen manier met de informatie want de distributie en verwerking van informatie is waar het immers om draait. Een controller zoals deze bedoeld is in MVC dient als de besturing van informatie, maar vooral om de 'routing' — wie heeft het nodig, wat is er nodig en hoe dient het te worden geleverd?

Een 'controller' is daarom eigenlijk het beste te omschrijven als een centrale punt - het is de 'interface' en werkt als een soort 'lijm' tussen de models en views; de controller werkt met de menselijke koppelingen (views) en de gegevensbronnen (models). Wie een controller ontwerpt zal dus moeten beginnen met een inventarisatie van de volgende punten:

• Voor welke informatie distributie dient de controller?
• Welke informatie zullen de views nodig hebben?
• Welke informatie is beschikbaar vanuit de modellen?
• Hoe dient de informatie te worden gecirculeerd?

Stel, we nemen een simpel ontwerp voor een controller die ontworpen moet worden voor het invoeren van artikelen. We noemen daarom dit ontwerp de 'Artikelen Controller'. De 'Artikelen Controller' moet artikelen kunnen opvragen, toevoegen, aanpassen, verwijderen. Omdat de Artikelen Controller werkt voor een website, is het handig om de artikelen in uniforme gegevens te verspreiden (zoals XML). We hebben eigenlijk de basis van het controllerontwerp nu al gelegd. Wanneer we de controller het verzoek doen voor een artikel ‘opvragen', dient de controller dit verzoek te honoreren door deze in XML formaat terug te geven. Wanneer we de controller vragen om het artikel te verwijderen, dan moet het artikel verwijderd worden waar deze ook opgeslagen zou mogen zijn.

Maar hoe weet een controller dan welk artikel verwijderd moet worden? Hier gaat het ontwerp vervolgens verder — wat is het ontwerp van een artikel? Heeft een artikel een eigen nummer? Heeft een artikel een unieke naam? Met parameters kunnen het ontwerp uitbreiden. Laten we op dit moment uitgaan dat ieder artikel een uniek nummer heeft. Dan wordt het ontwerp uitgebreid met de parameter 'id' (staat voor: identificatie). Er is geen limiet aan de hoeveelheid parameters die nodig zijn. Zo zal een zoekfunctie binnen een view artikelen willen opvragen op naam of inhoud.

Natuurlijk is dit verreweg een voorbeeld van dat gelijk staat binnen de industrie. Echter is het de bedoeling van een ontwerp dat het vooral duidelijk is wat er verwacht wordt van de handelingen die de controller moet uitvoeren.

©SamRain
Controller