Als Entwickler wollte ich mithilfe eines kleinen Artikels und eines interessanten spezifischen Projekts demonstrieren und mitteilen, wie einfach der NTi Data Access Provider auf einer DB2 for i-Datenbank zu verwenden ist: entwicklung einer .NET-API, die mit mehreren Datenbanken kommunizieren kann: DB2 for i auf einer IBM i-Partition und PostgreSQL-Container auf einem Raspberry pi, der wiederum mit dem IBM i verbunden ist.
Die Idee ist, parallel dazu eine clientseitige Anwendung zu entwickeln, die direkt von dieser API Daten im JSON-Format abrufen und sie auf dynamische, modulare und moderne Weise anzeigen kann.
Ich habe bereits einige Front-End-Anwendungen mit Nuxt JS erstellt, aber noch nie das JS-Framework Angular getestet. Dies wäre eine großartige Möglichkeit für mich, TypeScript kennenzulernen.
Erstellen der API
Schritt 1: Einrichten der Arbeitsumgebung
Ich beginne also mit der ASP .NET API-Umgebung direkt aus Visual Studio heraus, das eine sofort einsatzbereite Konfiguration mit Schlüsselwerkzeugen wie Swagger bietet, das natürlich in das .NET-Ökosystem integriert ist und es ermöglicht, seine API nativ effizient zu testen, ohne POSTMAN verwenden zu müssen.
Um SQL-Abfragen in jeder beliebigen Datenbank durchführen zu können, braucht man den richtigen Datenprovider (Treiber), der jeweils den ADO.NET-Standards entspricht, die eine Reihe von Klassen darstellen, die entwickelt wurden, um den Datenzugriff für .NET-Anwendungen zu erleichtern.
So kann man Daten manipulieren (lesen, schreiben, aktualisieren, löschen), indem man vertraute Objekte und Methoden verwendet (Unterstützung von SQL-Befehlen, Verwaltung von Verbindungen, Ausführung von Transaktionen, Manipulation von Abfrageergebnissen, usw.).
Ich wähle daher :
- NTi für DB2 for i
- NPGSQL für PostgreSQL.
Diese beiden Provider sind in NuGet referenziert, der NTi-Lizenzschlüssel ist bereits in die IBM i integriert, ich muss sie nur noch als Abhängigkeit meines Projekts herunterladen, und das war's.
Dann installierte ich Dapper, einen leichten Open-Source-ORM, der vom StackOverflow-Team entwickelt wurde, um diese beiden Datenbanken abzufragen; die automatische Zuordnung der Entitäten spart eindeutig Zeit.
Ich bin nun in der Lage, CRUD-Operationen zu erstellen und die einfache Ausführung von Abfragen hervorzuheben. Insbesondere bei NTi, das sich ohne Treiber, Overlay oder Einschränkungen mit DB2 for i verbindet, reicht es aus, die Verbindungskette im Programm zu konfigurieren.
Schritt 2: Datenmodellierung und Konfiguration der Services
Nachdem ich die für mein Projekt erforderlichen Datenanbieter integriert habe, mache ich mich an die interne Struktur der API.
Ich beginne damit, die verschiedenen Datenmodelle zu definieren, um sicherzustellen, dass ihre Handhabung und der Austausch zwischen der API und den beiden Datenbanken strukturiert sind.
Für jede Datenbank konfiguriere ich separate Verbindungsdienste unter Verwendung der beiden oben genannten Data Provider, um eine sichere und effiziente Verbindung herzustellen, die es der API ermöglicht, SQL-Abfragen auszuführen.
DB2Service:
PGSQLService:
Mit den Vorlagen und Diensten an Ort und Stelle kann ich dann die Controller erstellen. Sie verarbeiten die eingehenden Anfragen, führen die erforderliche Logik aus (CRUD) und senden die entsprechenden Antworten an die Clients zurück.
GET-Anfrage zum Abrufen von Kategorien:
POST-Anfrage, um eine neue Kategorie hinzuzufügen:
Damit die HTTP-Anfragen korrekt zu den Aktionen der Controller geleitet werden, habe ich ein präzises Routingsystem eingerichtet. Die Routen verknüpfen bestimmte URLs mit den Controller-Actions und stellen so sicher, dass jede Anfrage ihr in der API vorgesehenes Ziel erreicht.
Ergebnis der GET-Anfrage in Swagger:
Schema für die API-Anfrage, um eine neue Kategorie hinzuzufügen (POST).
Damit die externe Anwendung Daten von der .NET-API abrufen kann, füge ich schließlich eine CORS-Konfiguration (Cross Origin Resource Sharing) hinzu, um domänenübergreifende Anfragen sicher zuzulassen, sodass die Angular-Anwendung auf die API-Ressourcen zugreifen kann, ohne gegen die Gleichursprungsrichtlinie zu verstoßen.
Mit der nun konfigurierten und funktionierenden API ist sie nun einsatzbereit und ebnet mir den Weg zum nächsten Schritt, der Erstellung der Front-End-Anwendung.
Erstellung der Angular-Anwendung
Schritt 1: Einrichten der Angular-Umgebung
Ich beginne damit, die für Angular erforderliche Entwicklungsumgebung mithilfe von Node.JS und NPM einzurichten und die Angular Cli-Pakete zu installieren. Mit dem MVVM-Designmodell besteht die Idee darin, die Anzeigelogik von der Geschäftslogik zu trennen. Diesmal verwende ich Visual Studio Code, mit dem ich dank einiger praktischer Erweiterungen schneller entwickeln kann.
Schritt 2: Erstellen von Diensten und Datenmodell.
Ähnlich wie die .NET-API erstelle ich auch TypeScript-Datenmodelle, um die Daten in der Anwendung effizienter zu bearbeiten, zu speichern und zu verwenden.
Die Kommunikation mit der .NET-API erfolgt über die von Angular angebotenen Dienste, die das HTTP-Protokoll zum Austausch von Daten im JSON-Format verwenden.
Ich erstelle also verschiedene Dienste, die als Brücke zwischen der Angular-Anwendung und der .NET-API dienen. Jede Methode verwendet eine bestimmte URL, und ich kann nun die entsprechenden Methoden für jeden Dienst direkt von jeder Angular-Komponente aus aufrufen.
Schritt 3: Entwicklung von Komponenten
Das Prinzip und das Interesse von Angular liegt in der Verwendung von Komponenten, die aus einer TypeScript-Datei für die Datenmanipulation und die Geschäftslogik, einer HTML-Datei für die Templates und einer css- oder scss-Datei für den Stil bestehen. Diese Komponenten können ineinander verschachtelt werden und fördern die Modularität.
Indem ich separate Komponenten für verschiedene Teile der Benutzeroberfläche erstellte, konnte ich die in den Angular-Diensten definierten Methoden aufrufen, um die Daten von der API abzurufen.
So ist es ein Leichtes, mehr oder weniger komplexe Diagramme oder Berechnungen zu erstellen, die spezifischen Anforderungen entsprechen, und gleichzeitig von einer dynamischen Aktualisierung der Benutzeroberfläche mit extrem niedrigen Antwortzeiten zu profitieren.
Erstellung eines Balkendiagramms, um die Anzahl der Produkte nach Kategorie abzurufen:
Blick auf das Stabdiagramm, von meiner Angular-Front-Anwendung aus:
Sicht auf ein Kreisdiagramm, das die Produktbestände darstellt:
Fazit
Dieses Projekt zeigt nicht nur die Produktivitätssteigerung und Modularität des .NET-Ökosystems, sondern auch die Einfachheit und Effizienz von NTi beim Datenzugriff auf IBM i und bei der Erstellung von Fat-Client-Anwendungen.
Mit einem guten Verständnis der Prinzipien der objektorientierten Programmierung, der ADO .Net-Standards und natürlich der SQL-Sprache, unabhängig vom zugrunde liegenden DBMS, wird die moderne Entwicklung und Kommunikation mit verschiedenen Datenbanken wirklich zugänglich, einfach und ohne Einschränkungen.
Was ich schnell entworfen habe, ist ein perfektes Beispiel für eine der unzähligen Möglichkeiten, die unser Datenprovider Nti bietet und die die Bedeutung eines vereinfachten und schnellen Zugriffs auf die Ressourcen von so robusten Systemen wie dem IBM i verdeutlicht. Diese Ressourcen werden nicht nur zugänglich, sondern auch voll nutzbar für die Entwicklung bedarfsspezifischer Geschäftsanwendungen, und das ohne zusätzliche Komplexität.
Die Realisierung einer .NET-API, die gleichzeitig mit DB2 for i auf einer IBM i-Partition und einer PostGreSQL-Instanz, die auf einem mit der IBM i verbundenen Raspberry Pi containerisiert ist, kommunizieren kann, veranschaulicht die Vielseitigkeit und Effizienz unseres NTi-Data-Providers, eine perfekte Kommunikation orchestrieren zu können und dabei geschickt traditionelle und moderne Ressourcen miteinander zu verbinden.
Quentin Destrade