Seperation of concern in een MVC applicatie (#1)
383

De Microsoft implementatie van MVC voor webapplicaties is al weer een tijdje in de lucht en er zullen weinig organisaties zijn die momenteel nog nieuwe ontwikkelingen opstarten in de voorloper (webforms) van MVC. Het principe van de model – view – controller is ingevoerd om een betere scheiding van verantwoordelijkheden te bereiken en als je het goed gebruikt is dit ook het geval.

De view
De view vormt de UI die de gebruiker uiteindelijk op zijn scherm zal zien. Het is van belang om je te realiseren dat de view binnen de standaard implementatie van een MVC-applicatie op de server gemaakt wordt. Dit betekend dat opmaak en data in één html document naar de client worden gestuurd.

De controller
Verzoeken vanaf de client komen binnen (via MVC-routing) in de controller. De controller roept de business aan en geeft informatie door aan de view zodat deze gemaakt kan worden.

Het model
Het model is feitelijk het meest “grijze” object binnen de MVC-implementatie zoals Microsoft dat toepast. Wanneer je op Wikipedia opzoekt wat het model is, gaat het meestal over data die van de controller naar de view wordt gestuurd. Soms zie je deze implementatie vrij letterlijk terugkomen, waarbij ontwikkelaars alle logica van de applicatie in de controller plaatsen en het model niet meer is dan een data-object. Dit levert een applicatie op waarbij alle scheiding van verantwoordelijkheden verloren is gegaan omdat de controller in zichzelf in feite de applicatie vormt. Een betere implementatie krijg je met een controller die alleen verantwoordelijk is voor input en output. Een verzoek komt in de controller binnen en deze geeft dat verzoek door aan de business logica, de output hiervan wordt vervolgens door de controller doorgegeven aan de view. Vanwege deze manier van werken zie je een hoop teams de term model gebruiken als representatie van de business logica van de applicatie.

De standaard MVC-applicatie
mvc_17052016

Wanneer alle objecten binnen MVC hun rol vervullen, kom je tot een bovenstaande architectuur. Hoewel we in deze architectuur een goede scheiding van de business logica en de view logica hebben. Is er toch nog wel een probleem op te lossen: doordat de view op de server opgebouwd wordt, is de output van de controller feitelijk alleen te gebruiken als UI van de webapplicatie. Een externe app heeft weinig aan deze output.
Voor dit probleem zou ik graag een oplossingsrichting geven in deel 2 van dit artikel wat volgende maand gepubliceerd wordt.

Auteur: Menno Jongerius, Bergler Competence Center, mei 2016