MVC-architectuur

Naarmate moderne browsers krachtiger worden met rijke functies, is het bouwen van volwaardige webapplicaties in JavaScript niet alleen haalbaar, maar ook steeds populairder. Op basis van trends op HTTP Archive is de omvang van de geïmplementeerde JavaScript-code in de loop van het jaar met 45% toegenomen.

JS-overdrachtsgrootte en JS-verzoeken

Nu JavaScript steeds populairder wordt, zijn onze client-side applicaties veel complexer dan voorheen. Applicatieontwikkeling vereist samenwerking van meerdere ontwikkelaars. Het schrijven van onderhoudbare en herbruikbare code is cruciaal in het nieuwe webapp-tijdperk. De Chrome-app, met zijn rijke functies aan de clientzijde, is daarop geen uitzondering.

Ontwerppatronen zijn belangrijk om onderhoudbare en herbruikbare code te schrijven. Een patroon is een herbruikbare oplossing die kan worden toegepast op veelvoorkomende problemen bij het ontwerpen van software (in ons geval) bij het schrijven van Chrome-apps. We raden ontwikkelaars aan de app te ontkoppelen in een reeks onafhankelijke componenten volgens het MVC-patroon.

In de afgelopen jaren is een reeks JavaScript MVC-frameworks ontwikkeld, zoals backbone.js , ember.js , AngularJS , Sencha , Kendo UI en meer. Hoewel ze allemaal hun unieke voordelen hebben, volgt elk van hen een of andere vorm van MVC-patroon met als doel ontwikkelaars aan te moedigen meer gestructureerde JavaScript-code te schrijven.

MVC-patroonoverzicht

MVC biedt architectonische voordelen ten opzichte van standaard JavaScript: het helpt u beter georganiseerde en dus beter onderhoudbare code te schrijven. Dit patroon is gebruikt en uitgebreid getest in meerdere talen en generaties programmeurs.

MVC bestaat uit drie componenten:

model-view-controller

Model

Model is waar de gegevensobjecten van de applicatie worden opgeslagen. Het model weet niets van views en controllers. Wanneer een model verandert, zal het zijn waarnemers doorgaans op de hoogte stellen dat er een verandering heeft plaatsgevonden.

Om dit verder te begrijpen, laten we de Todo-lijst-app gebruiken, een eenvoudige webapp van één pagina die uw takenlijst bijhoudt.

model-view-controller

Het model vertegenwoordigt hier de kenmerken die aan elk actiepunt zijn gekoppeld, zoals beschrijving en status. Wanneer een nieuw actiepunt wordt gemaakt, wordt dit opgeslagen in een exemplaar van het model.

Weergave

Weergave is wat er aan de gebruikers wordt gepresenteerd en hoe gebruikers omgaan met de app. De weergave is gemaakt met HTML, CSS, JavaScript en vaak templates. Dit deel van uw Chrome-app heeft toegang tot de DOM.

In de bovenstaande takenlijst-webapp kunt u bijvoorbeeld een weergave maken waarin de lijst met takenlijstitems mooi aan uw gebruikers wordt gepresenteerd. Gebruikers kunnen ook een nieuw taakitem invoeren via een invoerformaat; de weergave weet echter niet hoe het model moet worden bijgewerkt, omdat dat de taak van de controller is.

Controleur

De controller is de beslisser en de lijm tussen het model en de weergave. De controller werkt de weergave bij wanneer het model verandert. Het voegt ook gebeurtenislisteners toe aan de weergave en werkt het model bij wanneer de gebruiker de weergave manipuleert.

Wanneer de gebruiker in de takenlijst-webapp een item als voltooid aanvinkt, wordt de klik doorgestuurd naar de controller. De controller wijzigt het model om het item als voltooid te markeren. Als de gegevens persistent moeten zijn, wordt er ook asynchroon opgeslagen op de server. Bij de ontwikkeling van rijke webapps aan de clientzijde, zoals Chrome Apps, is het ook van cruciaal belang dat de gegevens persistent blijven in de lokale opslag. In dit geval zorgt de controller ook voor het opslaan van de gegevens in de opslag aan de clientzijde, zoals FileSystem API .

Er zijn een paar variaties op het MVC-ontwerppatroon, zoals MVP (Model–View–Presenter) en MVVP(Model–View–ViewModel). Zelfs met het zogenaamde MVC-ontwerppatroon zelf is er enige variatie tussen het traditionele MVC-patroon en de moderne interpretatie in verschillende programmeertalen. Sommige op MVC gebaseerde raamwerken zullen bijvoorbeeld de weergave de veranderingen in de modellen laten observeren, terwijl andere de controller de weergave-update laten afhandelen. Dit artikel is niet gericht op de vergelijking van verschillende implementaties, maar eerder op de scheiding van zorgen en het belang ervan bij het schrijven van moderne webapps.

Als u meer wilt weten, raden wij u het online boek van Addy Osmani aan: Learning JavaScript Design Patterns .

Samenvattend: het MVC-patroon zorgt voor modulariteit voor applicatieontwikkelaars en maakt het volgende mogelijk:

  • Herbruikbare en uitbreidbare code.
  • Scheiding van weergavelogica en bedrijfslogica.
  • Maak gelijktijdig werk mogelijk tussen ontwikkelaars die verantwoordelijk zijn voor verschillende componenten (zoals UI-laag en kernlogica).
  • Gemakkelijker te onderhouden.

MVC-persistentiepatronen

Er zijn veel verschillende manieren om persistentie te implementeren met een MVC-framework, elk met verschillende afwegingen. Wanneer u Chrome-apps schrijft, kiest u de frameworks met MVC en persistentiepatronen die voor u natuurlijk aanvoelen en passen bij uw applicatiebehoeften.

Model doet zijn eigen persistentie - ActiveRecord-patroon

Populair in zowel server-side frameworks zoals Ruby on Rails, als client-side frameworks zoals Backbone.js en ember.js , legt het ActiveRecord-patroon de verantwoordelijkheid voor persistentie bij het model zelf en wordt doorgaans geïmplementeerd via de JSON API.

Een iets andere benadering dan het hebben van een model dat de persistentie afhandelt, is het introduceren van een afzonderlijk concept van Store- en Adapter-API. Store, Model en Adapter (in sommige frameworks heet dit Proxy) werken hand in hand. Store is de opslagplaats die de geladen modellen bevat en biedt ook functies zoals het maken, opvragen en filteren van de modelinstanties die zich daarin bevinden.

Een adapter, of een proxy, ontvangt de verzoeken van een winkel en vertaalt deze in passende acties tegen uw persistente gegevenslaag (zoals JSON API). Dit is interessant in het ontwerp van moderne webapps, omdat je vaak communiceert met meer dan één persistente gegevenslaag, zoals een externe server en de lokale opslag van de browser. Chrome Apps biedt zowel de Chrome Storage API als de HTML 5 fileSystem API voor opslag aan de clientzijde.

Pluspunten:

  • Eenvoudig te gebruiken en te begrijpen.

Nadelen:

  • Moeilijk te testen omdat de persistentielaag in de objecthiërarchie is 'ingebakken'.
  • Het is moeilijk om verschillende objecten verschillende persistente winkels te laten gebruiken (bijvoorbeeld FileSystem-API's versus geïndexeerde DB versus serverzijde).
  • Hergebruik van Model in andere toepassingen kan conflicten veroorzaken, zoals het delen van een enkele Klantklasse tussen twee verschillende weergaven, waarbij elke weergave op verschillende plaatsen wil opslaan.

Controller doet volharding

In dit patroon bevat de controller een verwijzing naar zowel het model als een datastore en is hij verantwoordelijk voor het behouden van het model. De controller reageert op levenscyclusgebeurtenissen zoals Laden, Opslaan en Verwijderen en geeft opdrachten aan de datastore om het model op te halen of bij te werken.

Pluspunten:

  • Gemakkelijker te testen, de controller kan een nep-datastore worden doorgegeven waar tests tegen kunnen worden geschreven.
  • Hetzelfde model kan worden hergebruikt met meerdere datastores door simpelweg controllers met verschillende datastores te bouwen.

Nadelen:

  • Code kan complexer zijn om te onderhouden.

AppController doet persistentie

In sommige patronen is er een toezichthoudende controller die verantwoordelijk is voor het navigeren tussen de ene MVC en de andere. De AppController bepaalt bijvoorbeeld dat een 'Terug'-knop de client van een bewerkingsscherm (dat MVC-widgets/formaten bevat) naar een instellingenscherm verplaatst.

In het AppController-patroon reageert de AppController op gebeurtenissen en verandert het huidige scherm van de app door een aanroep naar de datastore te doen om alle benodigde modellen te laden en alle overeenkomende weergaven en controllers voor dat scherm te construeren.

Pluspunten:

  • Verplaatst de persistentielaag nog hoger op de stapel, waar deze gemakkelijk kan worden gewijzigd.
  • Vervuilt controllers op een lager niveau, zoals een DatePickerController, niet met de noodzaak om meer te weten over persistentie.

Nadelen:

  • Elke 'Pagina/Scherm' van de app vereist nu veel standaardwerk om te schrijven of bij te werken: Model, Weergave, Controller, AppController.

MVC is cruciaal voor het ontwerpen van Chrome-apps. We raden de volgende CSP-compatibele MVC-frameworks aan voor het schrijven van veilige en schaalbare Chrome-apps:

Nuttige bronnen

Online

Boeken