5. Conclusie

We hebben de volgende client/server-applicatie gebouwd:

Om tot de definitieve versie van de code te komen, hebben we talrijke aspecten van de frameworks AngularJS en Spring 4 moeten toelichten. Dit document kan dus worden gebruikt om zich te verdiepen in het gebruik van deze twee frameworks. In paragraaf 1.3 wordt uitgelegd waar de codes te vinden zijn en hoe ze kunnen worden gebruikt.

We hebben aangetoond dat de client/server-applicatie in verschillende omgevingen kan worden gebruikt:

• als een klassieke webapplicatie;
• als een uitvoerbaar bestand op Android-emulators;

Nogmaals, deze tutorial is niet uitputtend wat betreft de behandeling van beide frameworks. Voor Angular zouden de bijbehorende testtools zeker aan bod moeten komen. Testen zijn onmisbare stappen bij het schrijven van een applicatie. Met de tools rondom Angular kunnen deze worden geautomatiseerd en opgenomen in een continu integratieproces.

Uit dit werk onthoud ik twee punten:

• het schrijven van de Spring-webservice was redelijk ingewikkeld. Vanaf het begin was ik goed bekend met de concepten van Spring. Ik ondervond alleen moeilijkheden bij het beveiligen van de webservice en later bij het beheer van de headers HTTP en CORS, twee gebieden waar ik geen kennis van had;
• het schrijven van de Angular-client was om verschillende redenen veel complexer:
  • ik had onvoldoende kennis van de programmeertaal JavaScript en de mogelijkheden ervan;
  • ik had moeite om te begrijpen hoe asynchroon programmeren in de browser werkte. Ik redeneerde alsof het op een server was, waar deze asynchrone werking wordt bereikt door het gelijktijdig gebruik van meerdere threads. In de browser is er slechts één thread, en asynchrone taken worden achtereenvolgens verwerkt en niet parallel. Om precies te zijn: asynchrone taken kunnen wel parallel worden uitgevoerd (bijvoorbeeld meerdere HTTP-verzoeken), maar de gebeurtenissen die ze genereren wanneer ze zijn voltooid, worden wel sequentieel verwerkt. Er is dus geen sprake van gelijktijdige uitvoering, met alle problemen van dien;
  • Angular is een uitgebreid framework met talrijke concepten (MVC, richtlijnen, services, modelbereik, ...). Het vergt veel tijd om het onder de knie te krijgen;
  • Angular schrijft geen specifieke ontwikkelingsmethode voor. Om tot hetzelfde resultaat te komen, kun je dus verschillende architecturen gebruiken. Dat is verwarrend. Ik voel me meer op mijn gemak bij gesloten frameworks waar iedereen dezelfde ontwerppatronen (design patterns) gebruikt. Ik heb daarom voortdurend geprobeerd de ontwerppatronen na te bootsen die ik aan de serverzijde gebruik. Ik ben tevreden met het resultaat, omdat ik denk dat het reproduceerbaar is. Dat is wat ik zocht. Maar ik weet helemaal niet of ik al dan niet ben afgeweken van de ‘best practices’ van Angular;

Serge Tahé, juli 2014.