A reasonable question about this topic is: What for …? Why it is needed to invent something and not to use proved and reliable good things (DB-ORMs). For the answer to this question we should pass to subitem below.

This is experimental project. Its goal is to obtain normal interoperation: C#-client vs. C#-server. And this is the main objective. We need to have a full freedom in writing C# client-server exchange protocol. Any dependency which dictate us its rules probably may impede us: strict naming rules, attributes and so on. We do not want duplicate our not simple and numerous exchangeable structures (data-models) to sutisfy such exacting subsystem. It is better to use our own, specially designed to our purpose.

Above mentioned is not concerning only ORM to database but also to JSON, whose explicit usage should be minimized in our Client-Server C#-interface. Here JSON-attributes for C# are used infrequently in user app.code (in BookRegistry WASM-application project).

Database data-models (structures) are normally declared only once in C# — simultaneously for server and client sides (with some differences, that is achieved via conditional compilation). This approach is used to form interaction API (Web-client—Web-server) with minimal involvement of usage of JSON-attributes for C#. Exchangeable C# data-models are implemented as so-called self-checking objects, with strict property getters applied to values, whose type (in C#) does not provide null. Such autonomous checking technique (C#-only) is used to guarantee consistency of nulls.
At client-side additional JSON-to-null checking is fired automatically by service invocation routine (in AFX) — when response-object is received from server. It is realized as so-called “back-packing”-test (in AFX) for the sake of null-checking (before access to response object properties from application writer client-code).

For DB-data extraction (through ADO.NET API) special accessors are used extensively in C# user-code,
like this: “public int Number = INT();” – for extraction of integer number field which may not contain null;
like this: “public string? Name { get; set; } = NS_N();” – for extraction of normalized string which may contain null;
or this: “internal DateTime? NDate = _DT();” – behind-field assignment for strict property named Date (of System.DateTime).
(Aboved denoted style is so-call imperative initialization of C# data-record during object-creation time.)

No automatic initializers (for data-record fileds) nor smart data-attributes for C# are provided in this simplified and experimental ORM. (Nevertheless using of imperative field initialization style is reasonably working approach.)

On side of Web-server service code is separated into following two different parts: “solid-code” (C#-controllers) and “soft-code” (procedural T-SQL). In spite of any difficulties of such division, soft-code is very useful thing, because it may be corrected on the fly, without need of server restart. Also the code may be changed by little pieces as opposed to solid C# EXE/DLL-recompilation.

In BookRegistry Web-server each query to database is represented by two nearly-situated files of same base-name: <NamedQuery>.sql and <NamedQuery>.cs. Such DB-query is visible not only for server-side C#, but also exposes correspondent data-structures and/or error-statuses for C#-client (WASM app.). Directives of conditional compilation are used intensively for the sake of flexibility (instead of simple DLL-sharing by means of .NET-standard format).

At DB-level — Transact-SQL is used for queries. SQL-code is maintained with help of SQL-file technology — lightweight scripting/command-line tools for Transact-SQL enhancement, which allows to organize SQL-project on base of traditional file/directory structure usage (for code-files), with corresponding code-translation: from SQL-files to SQL-database.
In BookRegistry-application SQL-code is located in following folders:
— “SHARED\$ClientServer\!DB-queries (application SP)”: top-level stored procedures;
— “SQL (DB-modelling)”: base stored procedures, table creation, initial data filling, data deletion, table-structure removal etc.

You can read about SQL-file on corresponding description page: SQL-file technology …

See also (SDK folder): “HandicraftSDK\SQL\Extralight-ORM test legacy sample (En+Ru)\Illustration (screenshots, fragments)\Stuctured ADO-queries (C#)”.