Skip to content

5. Wnioski

Stworzyliśmy następującą aplikację klient-serwer:

Image

Aby uzyskać ostateczną wersję kodu, musieliśmy wyjaśnić wiele kwestii dotyczących frameworków AngularJS i Spring 4. Niniejszy dokument może zatem służyć jako materiał szkoleniowy dotyczący korzystania z tych dwóch frameworków. W punkcie 1.3 wyjaśniono, gdzie znaleźć kody i jak z nich korzystać.

Wykazaliśmy, że aplikacja klient-serwer może być wykorzystywana w różnych środowiskach:

  • jako klasyczna aplikacja internetowa;
  • jako plik wykonywalny na emulatorach Androida;

Jeszcze raz podkreślamy, że niniejszy samouczek nie wyczerpuje tematu obu frameworków. W przypadku Angulara z pewnością należałoby omówić towarzyszące mu narzędzia testowe. Testy są niezbędnym etapem podczas pisania aplikacji. Narzędzia związane z Angularem pozwalają je zautomatyzować i włączyć do procesu ciągłej integracji.

Z tej pracy zapamiętam dwie rzeczy:

  • pisanie serwisu internetowego w Springu było umiarkowanie skomplikowane. Od samego początku dobrze znałem koncepcje Springa. Trudności napotkałem jedynie przy zabezpieczaniu serwisu internetowego, a później przy obsłudze nagłówków HTTP i CORS – były to dwa obszary, których wcześniej nie znałem;
  • tworzenie klienta Angular było znacznie bardziej skomplikowane z różnych powodów:
    • nie znałem wystarczająco dobrze języka JavaScript i jego możliwości;
    • miałem trudności ze zrozumieniem, jak działa programowanie asynchroniczne w przeglądarce. Rozumowałem to tak, jak na serwerze, gdzie asynchroniczność osiąga się poprzez jednoczesne wykorzystanie wielu wątków. W przeglądarce istnieje tylko jeden wątek, a zadania asynchroniczne są przetwarzane kolejno, a nie równolegle. Mówiąc dokładniej, zadania asynchroniczne mogą być wykonywane równolegle (na przykład wiele żądań HTTP), ale zdarzenia, które generują po zakończeniu, są przetwarzane sekwencyjnie. Nie ma więc do czynienia z wykonywaniem współbieżnym i związanymi z tym licznymi problemami;
    • Angular to bogaty framework zawierający wiele pojęć (MVC, dyrektywy, usługi, zakres modeli itp.). Jego opanowanie zajmuje dużo czasu;
    • Angular nie narzuca konkretnej metody programowania. Aby osiągnąć ten sam rezultat, można więc stosować różne architektury. To jest mylące. Lepiej czuję się w zamkniętych frameworkach, gdzie wszyscy korzystają z tych samych wzorców projektowych (design pattern). Dlatego nieustannie starałem się odtworzyć wzorce projektowe, z których korzystam po stronie serwera. Jestem zadowolony z wyniku, ponieważ uważam, że jest on powtarzalny. Właśnie tego szukałem. Nie mam jednak pojęcia, czy odszedłem od „dobrych praktyk” Angulara, czy też nie;

Serge Tahé, lipiec 2014 r.