Ontwerppatronen voor Cocoa MVC en MVVM

Ontwerppatronen maken de code van uw app modulair en vergevingsgezind als het gaat om het oplossen van bugs en wijzigingen. In dit artikel leert u over de ontwerppatronen MVC (Model-View-Controller) en MVVM (Model-View-ViewModel).

Hoewel ontwerppatronen (ook bekend als architecturale patronen) essentieel zijn voor de ontwikkeling van schaalbare Cocoa Touch-apps, is er veel controverse rond welk architecturaal patroon eigenlijk het beste is voor gebruik in uw app. 

Bekijk deze recente berichten van Bart Jacobs over MVC en MVVM voor meer perspectieven op deze ontwerppatronen en de keuze tussen deze patronen.

• 

  Waarom MVC misschien niet het beste patroon is voor cacao-apps

  Model-View-Controller (MVC) is een wijdverspreid patroon voor softwareontwikkeling. Leer wat MVC is en waarom het misschien niet de beste oplossing is voor Cocoa-ontwikkelaars.
• 

  Zet uw View Controllers op een dieet met MVVM

  Meer informatie over een alternatief voor het MVC-patroon: Model-View-ViewModel. Ik zal je laten zien hoe MVVM een aantal van de tekortkomingen van Model-View-Controller kan oplossen.

De verzameling objecten van een bepaald [architectonisch patroon] in een toepassing wordt soms een laag genoemd, bijvoorbeeld een modellaag. - Appel

Laten we zonder meer een paar ontwerppatronen bekijken die u in uw volgende app kunt gebruiken.

MVC (Model-View-Controller)

Dit is het meest gebruikte patroon in Cocoa Touch-ontwikkeling, en het is ook mijn persoonlijke favoriet. Dit ontwerppatroon sorteert uw code efficiënt en effectief in drie categorieën (of lagen): het model, de weergave en de controller.

Hoe werkt het en waarom zou ik het gebruiken?

Met dit ontwerppatroon kunt u wijzigingen aanbrengen in één laag zonder de andere lagen van het patroon te beïnvloeden. Als u bijvoorbeeld de database moet wijzigen, verwijdert u het model en vervangt u het zonder de weergave of controller te hoeven bewerken. Of als u de weergave van een weergave wilt wijzigen, hoeft u zich geen zorgen te maken over het verpesten van de databasecode. Dit wordt 'separation of concerns' genoemd en het maakt uw code eenvoudiger te debuggen, te onderhouden en opnieuw te gebruiken.

Bovendien is dit het ontwerppatroon dat door Apple zelf wordt aanbevolen, en het is een norm in de ontwikkelingsgemeenschap van iOS. Als je net begint, raad ik je ten zeerste aan om gewoon aan dit patroon te blijven. Je kunt verschillende ontwerppatronen later in je Cocoa ontwikkelingscarrière uitproberen.

Lagen en verantwoordelijkheden

Laten we de verschillende lagen in dit patroon van naderbij bekijken en bekijken waar ze verantwoordelijk voor zijn. Hier is een snel diagram van de interacties tussen de lagen:

Het MVC-ontwerppatroon scheidt elk deel van uw code in een van de drie delen: het model, de weergave en de controller. 

• Model: Deze laag is enkel en alleen verantwoordelijk voor de gegevens en de vorm zoals deze wordt weergegeven in uw app. De Controller-laag kan wijzigingen in de app-gegevens aanbrengen door het model op de hoogte te stellen. Het model is niet verantwoordelijk voor iets anders, inclusief hoe de gegevens aan de gebruiker worden getoond of wie of wat de gegevens gebruikt.
• Uitzicht: De weergave is verantwoordelijk voor de weergave van de gegevens-enkel en alleen hoe de gebruiker de gegevens ziet en gebruikt. Dit kunnen herbruikbare cellen, tabellen en andere elementen van de gebruikersinterface zijn die niets weten over de gegevens of hoe deze worden verwerkt. De gegevens worden door de controller aan de weergave-elementen geleverd.
  
• controller: De Controller is de ster van de show. Het brengt gegevens uit het model en geeft het vervolgens door aan de weergave die aan de gebruiker moet worden weergegeven. Dit is de enige laag tussen het model en de weergave, die enkele problemen kan veroorzaken, waarnaar we verderop in dit artikel zullen kijken. De controller wordt meestal geïmplementeerd in ViewController.swift,en het is verantwoordelijk voor het luisteren naar invoer en het wijzigen van het model als dat nodig is.

Eén ding om in gedachten te houden is dat je niet teveel verantwoordelijkheden in een van deze lagen moet proppen, want dat zou het doel van het hebben van een ontwerppatroon verslaan.!

En als je de verbindingen tussen de lagen niet schoon en helder houdt, krijg je uiteindelijk een rommelige en niet-verdedigbare app, ondanks het gebruik van het MVC-ontwerppatroon! Zorg in het bijzonder ervoor dat je niet doen laat het zicht en het model direct communiceren. Deze interacties moeten uitsluitend via de controller plaatsvinden.

MVVM (Model-View-ViewModel)

Hoewel het ontwerppatroon van Model-View-Controller vrij normaal is en in de meeste gevallen zou moeten werken, heeft het zijn eigen reeks uitdagingen en nadelen. Daarom hebben we een ander ontwerppatroon genaamd MVVM, wat staat voor Model-View-ViewModel.

MVC is geweldig, dus waarom heb ik MVVM nodig??

Welnu, er is een groot probleem waar je je bewust van moet zijn. Zoals je in het vorige gedeelte hebt gezien, is de Controller-laag de enige laag tussen de weergave en het model, dus het is niet verwonderlijk dat mensen deze laag misbruiken en er snel teveel dingen aan doen. Dit lijkt misschien het gemakkelijkste om te doen op het moment, omdat het de andere lagen vermijdt, maar uiteindelijk leidt het tot een opgeblazen Controller en moeilijk te onderhouden code.

Dit heeft ertoe geleid dat MVC in sommige kringen de grillige bijnaam "Massive-View-Controller" kreeg.

Het MVVM-architecturale patroon, dat werd geleend door Cocoa-ontwikkelaars van Microsoft, kan dit probleem van enorme view controllers helpen bestrijden. Hoewel het niet zo gebruikelijk is in iOS-ontwikkeling als MVC, wordt het in toenemende mate gebruikt om de tekortkomingen van MVC goed te maken..

Lagen en verantwoordelijkheden

Laten we eens kijken naar de verschillende lagen en hun verantwoordelijkheden in MVVM. (U moet waarschijnlijk opmerken dat er in de Cocoa-community geen formele richtlijnen zijn over het gebruik van deze lagen.) 

Hier is een snel diagram dat de lagen van dit architecturale patroon en hun verbindingen met elkaar laat zien.

Als je erover nadenkt, zie je dat hoewel views en controllers afzonderlijke lagen zijn in het MVC-ontwerppatroon, ze zeer nauw met elkaar zijn verbonden. Dus in MVVM nemen we eenvoudig de weergave en de controller en combineren ze tot één laag. 

Laten we elke laag vergelijken met zijn tegenhanger in het MVC-patroon. 

• (Weergave) Controller: Deze laag, meestal alleen bekend als de weergave, is nauw verbonden met de controller. Zoveel zelfs dat ze niet eens in verschillende lagen zijn verdeeld! Het uitzicht enkel en alleen communiceert met de Controller, maar de Controller communiceert met het ViewModel en de View. De weergave en de controller doen dezelfde taken als in MVC, maar het verschil is dat sommige taken die aan de controller zijn gegeven (in MVC) nu worden afgehandeld door een tussenlaag, het ViewModel, om misbruik van de controller te voorkomen. De weergave verwerkt nog steeds de weergave van gegevens voor de gebruiker en de controller reageert op gebruikersgebeurtenissen en communiceert met de rest van de lagen van het patroon.
• ViewModel: Deze laag bevat op zichzelf geen 'weergaven', maar verwerkt de logica achter het weergeven van weergaven, meestal presentatielogica genoemd. Dit omvat het maken van aangepaste opmaak- en verwerkingsreeksen om weer te geven, evenals het daadwerkelijk crunchen van getallen die aan de gebruiker moeten worden getoond op basis van de gegevens in de modellaag. 
  
• Model: Het model verschilt niet erg van de modellaag in het MVC-patroon. Zoals we eerder zagen, het Model enkel en alleen behandelt de gegevens en brengt wijzigingen aan in die gegevens als deze updates ontvangt van de ViewModel-laag. Het doet niet iets weten over wie de gegevens gebruikt, wat ze daarmee doen of hoe de gebruiker de gegevens ziet.

Zoals je eerder hebt gezien, moet je de verantwoordelijkheden van deze lagen niet mengen, omdat dit ertoe kan leiden dat je app-code een ingewikkelde spiraal vormt, waardoor het gebruik van elk ontwerppatroon overbodig wordt.

Conclusie

Ik hoop dat je het leuk vond om meer te leren over deze fundamentele ontwerppatronen voor iOS. Hopelijk heb je meer inzicht gekregen in de MVC- en MVVM-ontwerppatronen en heb je voldoende vertrouwen om deze te gebruiken in je toekomstige toepassingen. 

Natuurlijk is het architecturale patroon dat u voor uw app gebruikt helemaal aan u, en het hangt af van het type toepassing dat u probeert te ontwikkelen. Als u echter nog niet bekend bent met iOS-ontwikkeling, raad ik u toch ten zeerste aan om het MVC-ontwerppatroon te volgen, omdat dit nog steeds de meest gangbare methode is in de ontwikkeling van Cocoa..

Als je er nog bent, kijk dan eens naar enkele van onze andere tutorials en artikelen hier op Envato Tuts+!