Architektur von JavaScript-Applikationen

1. JavaScript Architektur
Erich Westendarp / pixelio.de

2. WER BIN ICH?
• Sebastian Springer
• https://github.com/sspringer82
• @basti_springer
• Consultant,Trainer,Autor

3. JavaScript
Applikationen?

4. Codeverteilung
Client/Server: 50/50
LOC: >1 Mio.
Budget:
> 1 Mio.
Businesskritische
Applikationen
Entwicklerteam:
> 20 Personen
Nicht
branchenspezifisch

5. Architektur in
JavaScript?

6. Architektur
Strukturierte oder hierarchische Anordnung der
Systemkomponenten sowie Beschreibung
ihrer Beziehungen. (Helmut Balzert)

7. Wozu Architektur?

8. birgitH / pixelio.de

9. Wartbarkeit

10. Finde den Fehler
Karl-Heinz Laube / pixelio.de

11. Erweiterbarkeit

12. Kosten/Zeit neuer
Features
Stefan / pixelio.de

13. Testbarkeit

14. Aufwand für Tests
uygar sanli / pixelio.de

15. Parallele Arbeit

16. Unabhängige Komponenten
Rainer Sturm / pixelio.de

17. Nerven der Entwickler

18. Paul-Georg Meister / pixelio.de

19. Also: Architektur FTW
Lutz Smolka / pixelio.de

20. Aber wie?

21. Multi-Page
vs.
Single-Page

22. Multi-Page

23. Multi-Page
Mehrere getrennte Seiten. JavaScript eher als
Unterstützung und nicht zwingend für die
Applikation erforderlich. Einfacher barrierefrei zu
gestalten. Oft für öffentliche Seiten und
Shops.

24. Single-Page

25. Single-Page
Nur eine/wenige Seiten. JavaScript zwingend
für die Applikation erforderlich. Navigation
und Abbildung der Business Logik über
JavaScript. Wird für Applikationen eingesetzt.

26. Global Scope
Thorben Wengert / pixelio.de

27. Global Scope
Namenskonflikte im globalen Namensraum.
Wiederverwendbarkeit wird durch
Unberechenbarkeit eingeschränkt. Ungewollte
Seiteneffekte durch gleiche Variablennamen.
Eingeschränkte Nachvollziehbarkeit des
Quellcodes.

28. Global Scope
• Funktionsparameter
• Dependency Injection
• Nur konstante globale Werte
• Singletons

29. Client vs. Server

30. Client vs. Server
Client Source Code wird statisch vom Server
ausgeliefert. Nutzdaten werden per Ajax-
Request im JSON-Format nachgeladen.

31. Separation der
Sprachen
H.D.Volz / pixelio.de

32. Separation der Sprachen
HTML für die Struktur, CSS für das Layout
und JavaScript für die Logik.
!
Pro Datei nur eine Sprache.

33. Modularisierung
Initiative Echte Soziale Marktwirtschaft IESM / pixelio.de

34. Modularisierung
Unterteilung der Applikation in den Kern und einzelne
Komponenten oder Module.
Der Kern stellt die Infrastruktur und die
Integrationsplattform für die Module dar.
Die Module beinhalten die einzelnen Features
der Applikation.

35. MVW
Model View Whatever

36. Model-View-Patterns
Separation von Datenhaltung und
Anzeigelogik in verschiedenen Ausprägungen.
Es gibt Frameworks, die diese Pattern
unterstützen.

37. MVC

38. MVC
Model View Controller
!
Seit 1979 in Smalltalk.
Models halten die Daten und die
Businesslogik.
Views visualisieren die Daten.
Controller verbinden die Models und die
Views miteinander.

39. MVC
Controller
Model
View
Benachrichtigt
Holt Daten Ändert
Events

40. MVP

41. MVP
Model View Presenter
!
Seit den frühen 1990ern.
Weiterentwicklung von MVC.
Konzentration auf die Präsentationslogik.
Presenter enthält die Anzeigelogik.

42. MVP
Presenter
Model
View
Daten
Events
Daten

43. MVVM

44. MVVM
Model View ViewModel
!
Seit 2005 von Microsoft.
Weiterentwicklung von MVC und MVP.
Model enthält Daten und Businesslogik.
Die View übernimmt die Anzeige.
ViewModel sorgt für die automatische
Datenbindung zwischen Model und View.

45. MVVM
ViewModel
Model
View
Daten
Databinding

46. Unterschiede
• Abhängigkeiten zwischen den Schichten
• MVC: View sitzt auf der Struktur parallel
zum Controller
• MVP: Controller wird durch Presenter
ersetzt (Events von Models und Views)
• MVVM: Es wird nur ein Teil des Models
der View bekannt gegeben

47. Frameworks
w.r.wagner / pixelio.de

48. Frameworks
Lösung für häufig auftretende
Problemstellungen. Hilfestellungen auch für
zukünftige Probleme, von denen man noch
nicht einmal weiß, dass man sie haben wird.
Bieten häufig Strukturierungselemente.
Basieren häufig auf jQuery.

50. Backbone.js
Einfaches Framework mit vorgegebenen
Model- und View-Strukturen.
Hash- und PushState-Navigation über einen
Router.
Sammlung von Models in Collections.!
Models sind REST-fähig.

52. Ember.js
Controller halten den Zustand der Applikation.
Models als Datencontainer, die über XHRs
mit dem Server kommunizieren können.
Handlebars als Template Engine.
Komponenten zur Erweiterung von HTML.
Models und Templates werden automatisch
synchronisiert. Router zur Navigation
innerhalb der Applikation.

54. AngularJS
Von Google seit 2009. Deskriptive
Programmierung. HTML als Templatesprache
wird durch Direktiven erweitert. Dependency
Injektion Mechanismus zur Auflösung von
Abhängigkeiten. Models als einfache
Datencontainer und Services für
wiederverwendbare Logik. Two-Way Data
Bindung über das ViewModel zwischen Model
und View. Unterstützt testbaren Code.

55. Module Loader
Peter Kamp / pixelio.de

56. Module Loader
Laden von JavaScript-Dateien ohne Script-Tag.
Auflösung von Abhängigkeiten. Potenzial
zur Optimierung einer Applikation.

57. RequireJS

58. RequireJS
Module Loader des Dojo Frameworks.
AMD Standard.
Im Wesentlichen zwei Funktionen: require &
define.
shim-Konfiguration für Bibliotheken ohne AMD.
r.js Optimizer zum Konkatenieren und
Minifizieren.

59. CommonJS Modules

60. CommonJS Modules
Serverseitige Standardisierung. Wird vor allem in
Node.js eingesetzt, aber auch clientseitige
Implementierung.
Definition über module.exports.
Einbindung über require.
Standardmäßig kein Optimizier.

61. ES6 Module

62. ES6 Module
Der neue JavaScript-Sprachstandard sieht ein
eigenes Modulsystem vor. Ein separater
Loader übernimmt das Laden der Module.
Aktuell noch keine Browserunterstützung.
Definition über module Keyword.
Zusätzlich gibt es noch import und export.

63. Fragen
Angela Parszyk / pixelio.de

64. KONTAKT
Sebastian Springer
sebastian.springer@mayflower.de
!
Mayflower GmbH
Mannhardtstr. 6
80538 München
Deutschland
!
@basti_springer
!
https://github.com/sspringer82