MQL: Eine hierarchische Abfragesprache mit TypeScript erstellen
Von Thomas Mahringer
()
Über dieses E-Book
In seinem shortcut zeigt Thomas Mahringer, wie das gelingt. Er erklärt, wie Sie mit überschaubarem Aufwand in TypeScript ein Domänenmodell mit einem daraus erzeugten maschinenlesbaren Schema und einer hierarchischen, JSON-basierten Query Language mit typsicherer Grammatik erstellen. Im weiteren Verlauf zeigt er, wie mit dieser auf relationale Datenbanken zugegriffen werden kann und wie die Antworten auf dem Client weiter verarbeitet werden.
Mehr von Thomas Mahringer lesen
Application Insights Bewertung: 0 von 5 Sternen0 Bewertungen
Ähnlich wie MQL
Titel in dieser Serie (100)
TFS 2012 Versionskontrolle: Grundlagen, Check-In Policies und Branch-Modelle Bewertung: 0 von 5 Sternen0 BewertungenErfolgreiche Spieleentwicklung: OpenCL Bewertung: 0 von 5 Sternen0 BewertungenAlgorithmen: Grundlagen und Implementierung Bewertung: 0 von 5 Sternen0 BewertungenEinstieg in Google Go Bewertung: 0 von 5 Sternen0 BewertungenSkalierbare Softwaresysteme: Design, Betrieb und Optimierungspotenziale Bewertung: 0 von 5 Sternen0 BewertungenIT Wissensmanagement: Theorie und Praxis Bewertung: 0 von 5 Sternen0 BewertungenZend Framework 2: Für Einsteiger und Umsteiger Bewertung: 0 von 5 Sternen0 BewertungenApache Tapestry: Einstieg in die komponentenorientierte Webentwicklung Bewertung: 0 von 5 Sternen0 BewertungenJavaScript für Eclipse-Entwickler: Orion, RAP und GWT Bewertung: 0 von 5 Sternen0 BewertungenJava EE Security Bewertung: 0 von 5 Sternen0 BewertungenAmazon Web Services für .NET Entwickler Bewertung: 0 von 5 Sternen0 BewertungenErfolgreiche Spieleentwicklung: OpenGL, OpenAL und KI Bewertung: 0 von 5 Sternen0 BewertungenJavaScript auf dem Server Bewertung: 0 von 5 Sternen0 BewertungenHTML5 Security Bewertung: 0 von 5 Sternen0 BewertungenJava 7: Fork-Join-Framework und Phaser Bewertung: 0 von 5 Sternen0 BewertungenTFS 2012 Anforderungsmanagement: Work Items und Prozessvorlagen Bewertung: 0 von 5 Sternen0 BewertungenADF - Mobile Apps entwickeln und Swing ablösen: Mobile Apps entwickeln und Swing ablösen Bewertung: 0 von 5 Sternen0 BewertungenGeolocation mit PHP: Foursquare-API, Google Places & Qype Bewertung: 0 von 5 Sternen0 BewertungenNFC: Near Field Communication für Android-Entwickler Bewertung: 5 von 5 Sternen5/5UX Design für Tablet-Websites: Ein Überblick Bewertung: 0 von 5 Sternen0 BewertungenHTML5 für Mobile Web Bewertung: 0 von 5 Sternen0 BewertungenC++: Kurzportträt einer zeitlosen Sprache Bewertung: 0 von 5 Sternen0 BewertungenÜberzeugende Präsentationen: Konzeption, Technik und Design Bewertung: 0 von 5 Sternen0 BewertungenMobile Business: Was Entscheider morgen wissen müssen Bewertung: 0 von 5 Sternen0 BewertungenEclipse meets Java FX Bewertung: 0 von 5 Sternen0 BewertungenQualität in IT-Architekturen: Strategie und Planung Bewertung: 0 von 5 Sternen0 BewertungenServiceorientierte Architektur: Anforderungen, Konzeption und Praxiserfahrungen Bewertung: 0 von 5 Sternen0 BewertungenQualitätssicherung mit JavaScript und PHP Bewertung: 0 von 5 Sternen0 BewertungenF#: Ein praktischer Einstieg Bewertung: 0 von 5 Sternen0 BewertungenBig Data: Executive Briefing Bewertung: 0 von 5 Sternen0 Bewertungen
Ähnliche E-Books
NoSQL Einführung: CouchDB, MongoDB und Regis Bewertung: 0 von 5 Sternen0 BewertungenCognitive Services Bewertung: 0 von 5 Sternen0 BewertungenSharePoint Kompendium - Bd. 15 Bewertung: 0 von 5 Sternen0 BewertungenSoftware Development Trends: Wegweisende Beiträge für eine neue IT: Wegweisende Beiträge für eine neue IT Bewertung: 0 von 5 Sternen0 BewertungenForms over Data mit Knockout.js: Die freie MVVM-JavaScript-Bibliothek im Praxiseinsatz Bewertung: 0 von 5 Sternen0 BewertungenGWT Best Practices II Bewertung: 0 von 5 Sternen0 BewertungenAufsetzen, Testen und Betrieb einer Android-App Bewertung: 0 von 5 Sternen0 BewertungenOWASP Top 10: Sicherheitslücken im Web Bewertung: 0 von 5 Sternen0 BewertungenKochen mit Patrick: Kochen und Programmieren - Hand in Hand Bewertung: 0 von 5 Sternen0 BewertungenClojure: Funktionale Programmierung für die JVM Bewertung: 0 von 5 Sternen0 BewertungenEnterprise Java Web Services Bewertung: 0 von 5 Sternen0 BewertungenJavaMoney: Einführung in den JSR-354-Standard Bewertung: 0 von 5 Sternen0 BewertungenStructr: Quelloffenes Daten-CMS auf Neo4j-Basis Bewertung: 0 von 5 Sternen0 BewertungenProgrammieren in TypeScript: Skalierbare JavaScript-Applikationen entwickeln Bewertung: 0 von 5 Sternen0 BewertungenBig Data: Datenverarbeitung basierend auf MOM und SQL Bewertung: 0 von 5 Sternen0 BewertungenJavaScript für Java-Entwickler Bewertung: 0 von 5 Sternen0 BewertungenDynamic Proxies: Effizient programmieren Bewertung: 0 von 5 Sternen0 BewertungenJavaScript und TypeScript für C#-Entwickler Bewertung: 0 von 5 Sternen0 BewertungenDSL mit Xtext/Xtend. 4GL-Entwicklung produktiver gestalten Bewertung: 0 von 5 Sternen0 BewertungenJavaScript für .NET-Entwickler Bewertung: 0 von 5 Sternen0 BewertungenSpring: Vier Perspektiven auf Framework und Ökosystem Bewertung: 0 von 5 Sternen0 BewertungenDurchstarten mit React: Web-Apps einfach und modular entwickeln Bewertung: 0 von 5 Sternen0 BewertungenDas Vulkan-API: Teil 1: Grundlagen und erste Schritte Bewertung: 0 von 5 Sternen0 BewertungenNeo4j 2.0: Eine Graphdatenbank für alle Bewertung: 0 von 5 Sternen0 BewertungenApps mit Azure Bewertung: 0 von 5 Sternen0 BewertungenOpenLaszlo: schnell + kompakt Bewertung: 0 von 5 Sternen0 BewertungenMicrosoft Azure: Cloud Entwicklung für lokale Applikationen Bewertung: 0 von 5 Sternen0 BewertungenServer-Infrastrukturen mit Microsoft Windows Server Technologien: Alle Themen für das Microsoft Seminar und die Zertifizierungsprüfung MOC 20413 Bewertung: 0 von 5 Sternen0 BewertungenGraphQL: Eine Einführung in APIs mit GraphQL Bewertung: 0 von 5 Sternen0 BewertungenDatenanalyse mit Microsoft Power BI und Power Pivot für Excel Bewertung: 0 von 5 Sternen0 Bewertungen
Datenbanken für Sie
Linux Grundlagen - Ein Einstieg in das Linux-Betriebssystem Bewertung: 0 von 5 Sternen0 BewertungenKeine Angst vor Microsoft Access!: Datenbanken verstehen, entwerfen und entwickeln - Für Access 2007 bis 2019 Bewertung: 0 von 5 Sternen0 BewertungenSQL von Kopf bis Fuß Bewertung: 4 von 5 Sternen4/5Datenintensive Anwendungen designen: Konzepte für zuverlässige, skalierbare und wartbare Systeme Bewertung: 0 von 5 Sternen0 BewertungenEinführung in SQL: Daten erzeugen, bearbeiten und abfragen Bewertung: 0 von 5 Sternen0 BewertungenBlockchain: Praktische Anwendungen, Praktisches Verständnis Bewertung: 0 von 5 Sternen0 BewertungenDokumentenmanagement mit Microsoft Access: Vollwertiges DMS mit Quellcode und Erläuterungen Bewertung: 0 von 5 Sternen0 Bewertungen
Rezensionen für MQL
0 Bewertungen0 Rezensionen
Buchvorschau
MQL - Thomas Mahringer
GmbH
1 Mit TypeScript Metadata und Reflection ein Domänenmodell aufbauen
TypeScript-Sprachkonstrukte ermöglichen es, mit überschaubarem Aufwand einen modellgetriebenen Ansatz aus folgenden Elementen zu etablieren: einem Domänenmodell, einem daraus erzeugten maschinenlesbaren Schema und einer pragmatischen, hierarchischen Query Language.
Webbasierte Applikationen haben sich zu Rich Clients entwickelt. Einer der Schwerpunkte bei datengetriebenen Rich Clients ist zweifellos ein möglichst effizienter und wartungsfreundlicher Datenaustausch mit Backends. Im Laufe der Zeit haben sich generische Abfragemethoden entwickelt, so z. B. OData, Facebook GraphQL oder Netflix Falcor. Da sie für möglichst breite Aufgabenstellungen konzipiert sind, bringen sie auch einen gewissen Overhead in Entwicklung und Ausführung mit sich. Wir wollen den Versuch wagen, mit den Konstrukten von TypeScript eine einfache, aber für die eigenen Bedürfnisse gut anpassbare Abfragesprache zu definieren. Die Basis dafür bildet ein Domänenmodell, das normale TypeScript-Klassen um Metadaten anreichert und aus dem ein maschinenlesbares Schema erzeugt wird. Letztendlich werden wir die in dieser Abfragesprache definierten Queries am Backend generisch auf eine relationale Datenbank mappen und das Ergebnis am Client typsicher verarbeiten. Durch die durchgängige TypeScript-Verwendung ersparen wir uns viel Overhead und schaffen Freiheitsgrade bei Design und Umsetzung.
Wissensmanagement oder Enterprise Relationship Management
Lassen Sie uns mit einem Beispiel aus der Praxis starten: In einem System, in dem es grob gesagt um das effiziente Verwalten und Wiederauffinden von Wissen oder Enterprise Relationship Management im weitesten Sinne geht, wird eine Vielzahl von Objekten logisch in einer netzwerkartigen Struktur gespeichert (Abb. 1.1).
Abbildung 1.1: Verwaltung eines Wissensnetzwerks, einer Ontologie
Die physische Speicherung soll jetzt noch nicht relevant sein, sondern nur, dass die Objekte sehr stark miteinander vernetzt sind: Personen, Kunden, Lieferanten, Verträge, Angebote, Mails, Projekte, Teilprojekte, Telefonate, Ressourcen, Aufgaben, Termine, Mitarbeiter und viele mehr. Schaut man sich das Ganze aus einer Domain-driven-Design-Sicht an, fällt schnell auf, dass sich keine klare hierarchische Struktur oder Aggregate Root finden lässt. Je nachdem, wer in welcher Rolle und welchem Anwendungsfall darauf sieht, ergeben sich beliebig viele Einstiegspunkte in das Beziehungsnetzwerk. Ein Projektleiter wird z. B. vorrangig über das Projekt einsteigen und will von dort aus möglichst schnell die zugehörigen Informationen finden. Ein Vertriebsmitarbeiter ist dagegen fast ausschließlich an der Sicht auf seine Kunden interessiert.
Das Grundproblem: Endpoint Mania, Data Overfetching und Underfetching
Wie man sich leicht vorstellen kann, ist nicht nur die endanwenderfreundliche User Experience eine Herausforderung, sondern auch, wie man die Datenabfragen möglichst effizient gestaltet. Abbildung 1.2 zeigt einen naiven Ansatz: Von einem REST-Endpunkt wird zunächst „meine Kunden" (eine Liste mit den IDs und Grunddaten der Kunden) geladen, danach werden die für den jeweiligen Screen relevanten Daten jeweils wieder über einen REST-Endpunkt geladen: die Anzahl der Einkäufe des Kunden, seine Stars (Bewertungen) usw.
Abbildung 1.2: Ein naiver Ansatz, der N+1 Roundtrips verursacht
Dieser naive Ansatz ist zur Laufzeit natürlich nicht haltbar: Wir verursachen N+1 Roundtrips vom Client zum Server und potenziell auch zur Datenbank.
Ein anderer, ebenfalls naiver Ansatz wäre es, alle benötigten Daten für den Screen auf einmal zu laden, z. B. in einem REST-Endpunkt: „Lade alle Kunden und ihre Zusatzdaten für den Screen ‚Meine Kunden‘. Wenn wir dann einen weiteren Use Case oder Screen, z. B. „Kunden mit offenen Bug-Anfragen
umsetzen, benötigen wir wieder etwas andere Daten, beispielsweise die Anzahl der offenen Bugs des Kunden oder seine Kundenzufriedenheit. Für diesen Fall liefert unser zuvor verwendeter Endpoint zu wenige Daten: sogenanntes Underfetching liegt vor. Wenn wir immer genau die passenden Daten pro Screen laden wollen, laufen wir schnell in eine Endpoint Mania (viele Endpoints für viele Use Cases), die unsere App nach kurzer Zeit unwartbar macht.
Last but not least versuchen wir es gleich mit dem Ansatz „alles in Bausch und Bogen": Wir laden sämtliche Daten, die wir zu einem Kunden benötigen: Grunddaten, Anzahl der Käufe, seine Stars, Anzahl der offenen Bugs, seine Zufriedenheit usw. Offensichtlich haben wir dann aber ein Overfetching, denn von all den geladenen Daten benötigen wir pro Screen nur einige wenige. Wir stecken in einem Dilemma: Viele kleine CRUD-ähnliche Services oder große/breite Services mit umfangreichen Rückgabemengen.
Navigieren im Netzwerk, jetzt wird’s hierarchisch
Zusätzlich zur