TORM

Prologue: We've Been Living in "Latency" for Too Long

What is the "optimal solution" for .NET's data access layer?
For the past decade, we've been caught in an endless pendulum swing.

On one side stands Entity Framework Core (EF Core), Microsoft's legitimate champion. It provides the sweet VR space of "abstraction," hiding SQL reality from developers. But its magic sometimes becomes a curse. Complex queries transform into unreadable monster SQL, dragging us into the abyss called performance tuning.

On the other side is Dapper. A hardcore micro-ORM that loves "raw" data. But in exchange, we must fight with unstructured data embedded as strings within C# code. No syntax highlighting, and "blobs of strings" that collapse with every refactoring are ticking time bombs in hyperscale systems.

"We don't want black-boxed magic. But we don't want primitive string manipulation either."

An answer has finally been presented to the thirst of architects in the field.
TORM (TERIOS Object Relational Mapping).

Inspired by "Doma" — which established the concept of "2-Way SQL" in Java's ecosystem and gathered passionate support — this ambitious work has been rebuilt using .NET's latest technologies (Source Generator / MEF2).

This is not just a library. It's a "Singularity" in system development. What we have here is an entirely new interface that creates a neural link between human thought and database execution engines.

In this article, we'll unravel the full picture of TORM through its four "revolutions."

Revolution 1: Cognitive Sync

Zeroing out the "translation latency" between brain and DB

What is the biggest productivity-killing noise in hyperscale development? It's not the time spent writing code. It's "translation" time.

Normally, when creating advanced queries, developers first dive into DB management consoles like pgAdmin or DataGrip. There, through trial and error, checking indexes and optimizing execution plans, they craft the "perfect logic."
The disconnect starts there. To bring that completed logic into the C# world, you must "translate" it.

"Dynamically concatenate this with StringBuilder..."
"Express this WHERE clause with LINQ Expression trees..."

Through this process, beautiful logic becomes a degraded copy, and an unbridgeable "cognitive gap" forms between DBAs and application engineers.

SQL is Code. Code is SQL.

TORM declares: "Save that SQL directly to a file. That is code."
TORM's 2-Way SQL allows SQL files to exist in "two quantum states."

SELECT
    p.product_name,
    SUM(o.amount) as total_sales
FROM orders o
INNER JOIN products p ON o.product_id = p.id
WHERE 1 = 1
/*%if (phase != null) */
  AND o.phase = /* phase */'ALPHA'
/*%end*/
/*%if (threshold > 1000) */
  AND o.amount >= /* threshold */1000
/*%end*/
GROUP BY p.product_name

This .sql file is a dimension-crossing interface.

What you have is the experience of "your conceived logic becoming the driving force of your app without delay." In a world without the noise of "translation," the developer's brain and database stay constantly synchronized.

Revolution 2: Compile-Time Precognition

Eliminating "uncertainty" and determining the future

In systems running thousands of queries, most bugs stem from the uncertainty of "not knowing until you run it."
"Modified module A, and module B's query — with no dependency — collapsed."
Such trivial entropy increases kill massive systems.

TORM's Source Generator burns away all this uncertainty at compile time.

Future Prediction by the Compiler

The moment you define a partial method, TORM's generator scans your entire project across time and space.

This isn't "testing." It's "Precognition."
In TORM's world, bugs aren't discovered at runtime — they're eliminated while writing code. This "deterministic build" is the only survival strategy in hyperscale development.

Revolution 3: Universal Design

Transcending host languages — the "Smalltalk" DNA

When you witness TORM's implementation, a sharp architect will immediately understand.
This is not a C# library. It's "a pure concept implemented in C#."
The true intent of TERIOS architecture is the complete liberation of logic from the narrow cage of the host language (C#).

Binding through Smalltalk-derived "Contracts"

TERIOS adopts Contract Names for component resolution.
This is an extremely pure object-oriented approach originating from Smalltalk's messaging philosophy.
It doesn't depend on "language-specific DI features" like Java annotations or C# generics — it binds systems only through contracts as strings.

Why? Because TERIOS is a "next-generation architecture" designed to be ported to any programming language.

For TERIOS, C# is merely a temporary "host." ComponentFactory is a universal interface to keep logic loosely coupled across language barriers.

This is a device to evolve systems from "solid" to "fluid."

Separation by Contract, Binding by Configuration

In TERIOS architecture, components are managed not by Type but by Contract Name.
Multiple implementations with the same interface can be deployed simultaneously under different names.

• ▶ CustomerDao (Standard implementation in stable operation)
• ▶ CustomerDao_Fast (High-speed version with cache layer)
• ▶ CustomerDao_Experimental (Version with experimental algorithms)

Which one to activate is determined solely by rewriting a configuration file.

{
  "CustomerDao": "CustomerDao_Fast"
}

Real-Time Adaptation

No need to modify code, rebuild, and redeploy. Rewrite the config file, and logic mutates instantly.
If an anomaly is detected at midnight, just revert the config to the standard implementation — rollback complete in 1 second.
"Test new logic on specific nodes only using production data." Such dangerous yet alluring experiments become possible without touching existing code.

Managing system implementation versions outside of Git (in the operational phase). Traditional CI/CD flows are too slow to keep up with this speed.

Revolution 4: AI-Native Protocol

A protocol designed not for humans, but for AI

This is the most modern and critical point.
TORM's "overly strict conventions" aren't meant to constrain humans.
They're a protocol "for AI (LLMs) to write perfect code without hallucination."

In modern development, assistance from AI agents like GitHub Copilot and ChatGPT is essential. However, overly flexible frameworks cause AI to hesitate and generate noisy code.
TORM's strictness becomes a "runway" for AI.

Technical Singularity: Challenging Physical Limits

It's not just concepts. TORM also challenges the physical limits of performance.

Warp Drive: PostgreSQL COPY (BulkCopyAsync)

"I want to transfer millions of records for initial data load." At such times, ORM's politeness becomes a hindrance.
BulkCopyAsync in the TORM.PostgreSQL package ignores EntityListeners and optimistic locking entirely, directly hitting PostgreSQL's binary transfer protocol (COPY command).
This achieves transfer speeds in an entirely different dimension from normal INSERT statements. "Ensure consistency through architecture. TORM just provides speed at physical limits."

Zero-Latency Parser: Pidgin Engine

A trap many custom ORMs fall into: "SQL parsing with regular expressions."
TORM makes no compromises here either. It adopts the parser combinator library Pidgin, analyzing SQL not as strings but as structured AST (Abstract Syntax Tree).
Parse results are cached with SHA256 hashes, achieving execution speeds approaching static SQL while remaining dynamic SQL.