.NET client Wkl.Data.Gateway.Client—overview
Typed access from .NET programs to the data service Wkl.Data.Gateway: reading with field selection, filter, sorting, and window, and calling procedures. The application never opens a database connection itself. The client is part of Database Gateway.
Where to start
| You want to … | Page |
|---|---|
| read and call a procedure | Read and call |
| set the address, key, and time limits | Configuration |
| know what the client deliberately doesn't do | Limits and properties |
| classify an error | A request fails with `GatewayRequestException` |
| look up methods, types, and values | API reference |
Why this detour exists
Only the data service opens database connections, never the application. There are two reasons for this:
- Connection strings exist in one place only. They aren't in the application, in a business module, or in a configuration file that ships with the application.
- Queries are checked in one place. The service checks field names, sort orders, and callable procedures against the database catalog and the key's rule before it builds a statement.
For this repository, the build checks the boundary automatically: no project in it may reference a database driver or an object-relational mapper. This check doesn't apply to the application that uses the client; there, the boundary is a rule of its own build. It only takes effect when the application has no connection string and no network access to the database—operations ensure that, not the client.
Sign-in with a key. The client sends a key from an environment variable in the service's key
header. This can be a service key—then the service sees the application—or a person's personal
key, in which case that person's rules apply. Windows account, SQL Server login, and second factor
aren't part of the client: if a sign-in rule of the service requires a second factor for the key,
every request fails with Unauthenticated. If you need these sign-in methods, address the service
through the ODBC driver or directly over HTTP.
What the client can't do—and why
It accepts no SQL. If you need a particular shape of data, create it as an object in the database (view, function, procedure) and read it through the existing interface. The data service does accept SQL text, for tools such as Access that send joins and totals as SQL: as checked statements, which it parses and checks against the catalog and the per-object rights, and, with a separate right, as unchecked text. The client deliberately doesn't offer this route: an application that assembles its queries as text loses the checking of field names and objects while the request is built, and any mistake in it only shows up in the service or the database.
Nor does it combine several responses. Every read method issues exactly one call and returns its result unchanged. Each method therefore corresponds to exactly one nameable object in the database.
Changes per version: Changes.
Manufacturer
EMSR DATA, D.O.O., Trg komandanta Staneta 8, 1000 Ljubljana, Slovenia
Email: Wolfgang.van.der.Stille@gmail.com, zp@datecpro.de
Website: https://wvds.it
“The White Knight Labs” and “WKL” are trademarks of EMSR DATA, D.O.O. How to report a
vulnerability and which versions are supported until when is described in SECURITY.md, the
manufacturer information in MANUFACTURER.md, and the license terms of EMSR DATA in LICENSE.md
(the English version is binding); all three are in the package, also in German and Slovenian.
From 0.3.1 on, sbom.cdx.json in the package is the software bill of materials (SBOM) in
CycloneDX 1.6 format: the library with its checksum and the NuGet packages it depends on.