.NET-Client Wkl.Data.Gateway.Client – Überblick

Typisierter Zugriff aus .NET-Programmen auf den Datendienst Wkl.Data.Gateway: lesen mit Feldauswahl, Filter, Sortierung und Fenster, Prozeduren aufrufen. Die Anwendung öffnet dabei nie selbst eine Datenbankverbindung. Der Client gehört zu Database Gateway.

Nur der Datendienst öffnet Datenbankverbindungen, nie die Anwendung. Das hat zwei Gründe:

1. Verbindungszeichenfolgen existieren nur an einer einzigen Stelle. Sie liegen nicht in der Anwendung, nicht in einem Fachmodul und nicht in einer Konfigurationsdatei, die mit der Anwendung ausgeliefert wird.
2. Abfragen werden an einer einzigen Stelle geprüft. Feldnamen, Sortierungen und aufrufbare Prozeduren prüft der Dienst gegen den Katalog der Datenbank und die Regel des Schlüssels, bevor eine Anweisung entsteht.

Für dieses Repository prüft der Bau die Grenze automatisch: Kein Projekt darin darf auf einen Datenbanktreiber oder einen objektrelationalen Abbilder verweisen. Für die Anwendung, die den Client benutzt, gilt diese Prüfung nicht; dort ist die Grenze eine Regel ihres eigenen Baus. Wirksam wird sie erst, wenn die Anwendung keine Verbindungszeichenfolge und keinen Netzzugang zur Datenbank hat – das stellt der Betrieb sicher, nicht der Client.

Anmeldung mit einem Schlüssel. Der Client schickt einen Schlüssel aus einer Umgebungsvariablen in der Schlüsselkopfzeile des Dienstes. Das kann ein Dienstschlüssel sein – dann sieht der Dienst die Anwendung – oder der persönliche Schlüssel einer Person, dann gelten deren Regeln. Windows-Konto, SQL-Anmeldung und zweiter Faktor gehören nicht zum Client: Verlangt eine Anmelderegel des Dienstes für den Schlüssel einen zweiten Faktor, scheitert jede Anfrage mit Unauthenticated. Wer diese Anmeldearten braucht, spricht den Dienst über den ODBC-Treiber oder unmittelbar per HTTP an.

Er nimmt kein SQL entgegen. Wer eine bestimmte Datenform braucht, legt sie als Objekt in der Datenbank an (Sicht, Funktion, Prozedur) und liest sie über die vorhandene Oberfläche. Der Datendienst nimmt SQL-Text zwar an, für Werkzeuge wie Access, die Verbünde und Summen als SQL schicken: als geprüfte Anweisungen, die er zerlegt und gegen Katalog und Rechte je Objekt prüft, und mit einem eigenen Recht als ungeprüften Text. Der Client bietet diesen Weg bewusst nicht an: Eine Anwendung, die ihre Abfragen als Text zusammensetzt, verliert die Prüfung von Feldnamen und Objekten beim Erzeugen der Anfrage, und jeder Fehler darin zeigt sich erst im Dienst oder in der Datenbank.

Ebenso wenig führt er mehrere Antworten zusammen. Jede Lesefunktion setzt genau einen Aufruf ab und gibt dessen Ergebnis unverändert zurück. Jede Methode entspricht deshalb genau einem benennbaren Objekt in der Datenbank.

Änderungen je Version: Änderungen.

EMSR DATA, D.O.O., Trg komandanta Staneta 8, 1000 Ljubljana, Slowenien
E-Mail: Wolfgang.van.der.Stille@gmail.com, zp@datecpro.de
Website: https://wvds.it

„The White Knight Labs“ und „WKL“ sind Marken von EMSR DATA, D.O.O. Wie Sie eine Schwachstelle melden und welche Versionen bis wann unterstützt werden, steht in SECURITY.md, die Herstellerangaben in MANUFACTURER.md, die Lizenzbedingungen von EMSR DATA in LICENSE.md (verbindlich ist die englische Fassung); alle drei liegen im Paket, auch auf Deutsch und Slowenisch. Ab 0.3.1 ist sbom.cdx.json im Paket die Software-Stückliste (SBOM) im Format CycloneDX 1.6: die Bibliothek mit Prüfsumme und die NuGet-Pakete, von denen sie abhängt.