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

Dit artikel is een vervolg op een introductie artikel over MVC. In dit artikel ben ik ingegaan op de opzet van een standaard MVC-applicatie.

14062016_mvc1

Het gevolg van deze standaard architectuur is dat de output van de controller een gesloten applicatie geeft waar derden niet eenvoudig gebruik van kunnen maken. Dit maakt dat de applicatie niet eenvoudig is te gebruiken voor andere doeleinden dan de website waar hij voor ontwikkeld is. In de huidige wereld van softwareontwikkeling is een open en modulaire architectuur een belangrijke meerwaarde voor een hoop organisaties.

Oplossingsrichting
14062016_mvc2

Maak gebruik van een Web-API voor de interactie met data. De opmaak die de webapplicatie nodig heeft wordt door een standaard controller en views geleverd, maar dit zouden ook gewoon platte html-files kunnen zijn. De data en interactie met de backend vindt plaats via de API-controller. Het plezierige van deze opzet is dat de kennis die teams al hebben opgedaan in MVC te herbruiken is omdat Web-API voortborduurt op MVC. Omdat de API enkel data communiceert is de applicatie open om te communiceren met willekeurig welke client applicatie. Wanneer je de applicatie netjes modulair opzet geeft dit je een goede basis om een applicatie te ontwikkelen die relatief eenvoudig op allerhande platformen te gebruiken is.

Front-end applicatie
In een standard MVC-webapplicatie wordt de client applicatie gevormd door de MVC-controllers en views. In de voorgestelde oplossing, schuif je de client feitelijk op naar de browser. Hiervoor kun je gebruik maken van legio technieken, en mocht je hier verder in willen duiken zou ik je adviseren eens een kijkje te nemen bij het Angular framework: http://dotnetspeak.com/2015/06/angular-2-in-visual-studio-2015-with-typescript

Auteur: Menno Jongerius, Bergler Competence Center, juni 2016