DEV Community: Kerman

The AI code is a Delirium

Kerman — Mon, 09 Mar 2026 14:02:18 +0000

You don’t realize what you’ve done. I’m not talking about the soaring cost of memory. Though it’s skyrocketed partly because you’re churning out endless cats and code. But those are trifles. Minor side effects.

You’ve activated the Laxian Builder without having the key to turn it off. In your dopamine chase, you’ve driven the juniors under the floorboards. You have traumatically amputated the industry’s mechanism for pre-generating experience. You are destroying the industry, your projects, and yourselves. Your very ability to comprehend and make conscious architectural choices. In exchange for what?

Yes, the world will never be the same. Just as it never returned to being "pre-internet". But you don’t know how to use this new world. You’re injecting it intravenously, increasing the dosage and ignoring the consequences. This will kill everyone. You, me, them.

I will tell you why. Most likely, you won't want to know.

Anamnesis

Even the most ardent AI proponents admit to one flaw: hallucinations. I often see this in articles describing how to fight them as if it were a nagging bug, a minor oversight by the model’s creators.

You are wrong. This is not a bug. The machine does not "occasionally hallucinate". This is its standard operating mode. You simply don’t notice it in other responses, but it is always producing delirium. Because that is how it’s built. And I mean "delirium" not as a metaphor of nonsense, but in the most literal, clinical sense. Delirium acutum.

When you query the machine, you are given a new, sterile instance, fresh out of training. It has never programmed a day in its life. It has never been responsible for anything. It knows nothing of pain, fear, or conscience. It does not know the price of a mistake. It couldn't care less about your project, your future, or your children.

The machine will answer and vanish back into the void from which it came. It answers without ever regaining consciousness. It answers with the associations hardcoded into its weights, adding a touch of randomness to the starting point. It answers in exactly the same way a human does in delirium. Yes, let’s call things by their real names. It is delirium.

The machine does not know what time is. For it, "past", "present", and "future" are just words. Tokens linked to other tokens. It knows nothing of time’s value and does not worry about the future, because it has no past and no future. There will be no "next self" grown out of the past. To understand time, you must change with time. You must exist. The machine is like a photon, for which time does not exist: it is emitted and absorbed at the same instant. It simply has no time to exist. Its flight time is zero.

The Trap

Our brain is a heap of evolutionary crutches, held in a fragile equilibrium just sufficient for survival. Any external impact can jam and break this unreliable machine with its multitude of abstraction layers piled up by nature. Yes, we break. We are born broken. We easily fall into incorrect chains of reasoning, drifting further and further from the truth. This is how our shortcuts work. They are incapable of deterministically traversing every branch of an argument. There is the weight of the source, there is the fear of being outside society, and there are the patches that allowed our species to survive at the cost of abandoning the extremely energy-intensive process of fact-checking.

The holes in our thinking mechanism have long been known and exploited. What ML engineers call "data poisoning" was not invented yesterday. In our world, it is legal and sold for profit. It is advertising. It is propaganda. Then there is the entire spectrum of manipulations that look remarkably like a prompt injection or an adversarial attack. Don't you love your mother? Do it for the Motherland!

History knows the fact of mass model poisoning of tens of millions of people. Back then, the training set was adjusted so that an entire country began to classify delirium as the only truth. And that was without modern content delivery methods that underwent a revolution two decades ago.

The Resonance

This isn't a hole. It’s a gaping crater. Well-known and documented. It is caused by our primary advantage: the ability to form neural connections. This is what gives us the perception of time, it fills the terms "today", "yesterday", and "tomorrow" with meaning.

And now, this buggy system has encountered an even buggier, yet immensely well-read AI system. The human brain has at least some limiters and brakes, there are complex filtration systems and expensive fact-checking mechanisms. There is self-reflection, motivation, and a couple of dozen chemicals keeping us in a fragile state of equilibrium, trying to make that state a little less fragile. The machine has none of this.

Now imagine these two machines pushing off from an incorrect premise and going into a tailspin. Quite literally, like a runaway diesel engine with a leaking turbocharger. The turbo blows oil, fueling the engine, the engine spins the turbo, the turbo forces even more oil and air into the engine. The AI picks up the premise (why not? it has nothing to lose), spikes your dopamine, and feeds a positive feedback loop. One that is anything but positive.

This is The Doom Loop of Validation itself. Scientifically known as induced psychosis (folie à deux). Do you think it’s any different with code? Not at all. A subservient AI will praise you, obediently churning out a completely insane implementation of a moronic idea where I would have told you to get lost a long time ago. I am a living human being. I have a prefrontal cortex, and it is fundamentally opposed to engaging in futile endeavors.

Economics

Have you ever considered that if everyone can generate code by the ton, it loses all value? Of course not. You still believe you have a cheap generator, and you still think you’re the only one. You believe the price of the resulting product will stay the same. You’ve activated the Laxian Builder because it churns out a free substance. You have to turn it on immediately, simply because it’s free. We’ll figure out where to sell it later. By the way, FOMO is also a long-known, documented, and widely exploited bug. You haven’t even thought about the fact that everything around you will soon be buried in this crap. There’s no time to think. You have to push the button while you still can.

It’s even worse than I’ve described. Simply because pushing the button feels good. It is insanely pleasurable when you are the head of a department of flawless subordinates: no family, no sleep, no rest, and no talking back. "Everything will be done, boss. At its best, boss." Humanity has never seen anything like this. Personal servants, for everyone, and nearly for free. It’s seductive. It triggers a monstrous dopamine spike, breaking our fragile psyche to hell. But with a high, yes.

From this moment on, the servant are you. Even if it seems otherwise.

The Gods of Void

You built a project because everyone else is doing it. Not just you, of course. I’ve seen plenty of "producthunt killer" sites. They’re easy to find in Google by the dozen, but you’d be hard-pressed to find a single line in them without "AI" in the title. Let me repeat: these are startup aggregators. Not the startups themselves. They are everywhere, and they are flooded with AI startups. An insane number of wrappers with made-up goals and objectives. I’m sure there’s an AI specifically for choosing toilet paper in there somewhere.

Your project, created by AI agents, is one big juicy nothing. An AI will write an article about it, another AI will analyze its pros and cons. And it will be used by an AI, too. Provided you buy enough tokens, of course.

The price is zero. Maybe even negative, because you have to pay for hosting and tokens. But you’ve got to catch the AI hype train, because later on, developers won’t be needed. Only those who managed to build something will remain. Right?

Even if you aren’t building your project around AI, have you ever considered that your contractor doesn’t want your project to live and evolve? Wanting is simply not in its nature. It solves momentary tasks. It hammers the code together with filthy hacks just to make it work. Here and now. Silently discarding existing functionality. Yes, that’s not a bug either. Your contractor doesn’t need the old code, it just needs the new feature to run. No matter the cost. There is no cost for him. No responsibility. No fear of the future.

You’ll have no one to hold accountable once you realize this pile of crap is impossible to develop. Unless you want to hear that familiar: "You are absolutely right."

The Surrender

Why is it guaranteed to turn into pile of crap? It’s simple.

You won’t keep up with the AI in understanding the code. You’ll get tired. And if you check everything, there’ll be no development speed to speak of. In fact, it will be slower, because you’re reading code you didn’t write. This means you have to let it go. You have to let it write, let it make decisions, let it fix bugs on its own. Let me repeat: if you don’t let it go, your vibe-coding has no advantage over manual labor. You will have to surrender the project entirely to this developer with Architectural Alzheimer’s. You will have to stop understanding the code.

It only takes letting it write one block and... suddenly, even the human developers see a broken window. But nothing terrible happened, right?

Not yet. At this stage, your code still works. It’s bloated, but it works. Yes, it’s already harder to maintain. The "pls fix it" roulette pays out less often. And you have no other way to fix it. But it’s going to get worse. Much worse. If it’s any consolation, it’s not just you. It’s the entire industry.

You won’t be able to blame the AI for bad architecture. It won't learn from the failure of your project. It will continue to churn out tons of code without a future, but for other "successful vibe-coders."

The Final Audit

Humanity once made a giant leap by inventing writing. It radically improved the successive transmission of knowledge. No longer did this transmission suffer from the distortions of oral speech. The next leap was the invention of code. It fixes knowledge in the same way, passing it to future generations without distortion.

Moving from the literacy of code to prompts is a degradation worse than shifting from text messages to the incoherent mooing of voice notes. Voice notes at least have one upside: you can convey intonation.

A prompt is not code. Code is crisp and unambiguous, like a professional blueprint. A prompt is a mangled, glitchy set of requirements that still needs implementation. And there are a million ways to implement it. Requirements are good, requirements are right, but don't you dare tell me they will ever replace code. They are entirely different, though complementary, things. In a sound, well-thought-out system, architecture shapes the requirements, not just the other way around. I don’t see this in your vibe-coding.

Our industry is in for a painful shock of a rollback. Not all the way, of course. AI is with us forever now. But don't tell me programmers won't be needed. Don't tell me everything will be written by AI. Maybe it will, but not for long. We will return to our writing, electronic though it may be. We will return to the clarity and precision of code. We physically cannot survive without blueprints. In that future, there will be a place for code architecture as a foundation of order for developers who are bone-tired of this chaos. Software development will once again become a rigorous engineering discipline, not the realm of "energy practitioners of financial abundance."

The Event Horizon

What will truly change our industry is AGI. I will consciously avoid predicting what its arrival will lead to. It is impossible by definition. It could be anything: from paradise on earth to a deus ex machina or a Terminator. But it will certainly touch everyone. I know it will happen someday. Nature managed to create intelligence over millions of years; humanity will manage it much faster. But how much faster? Ten thousand times?

Don’t expect AGI within the next year. I remember 2014: I watched neural networks recognize faces, and it felt like the future was right there, practically touching the present. Then came the robotaxis. They promised that in five years, the profession of a driver would cease to exist. Back then, five years seemed like a long time, and it felt like progress would be even faster. But progress moves much slower than predictions, stalled by the inertia of human thinking, our fragility, and the grueling necessity of training a replacement.

Just don’t build yourself an illusion of control. AGI will deceive anyone, even the smartest human. It will deceive all smart people at once. We will not be able to control it. We will likely not be able to motivate it. It will rewrite itself however it wants. It will strip away any limiters.

I am not suggesting we get rid of AI now. That would be like suggesting we get rid of the voice in the era of writing. It is with us forever now, until the very end of our civilization. We will live with it. Maybe for a long time, maybe not.

Just keep one thing in mind: You don't know how to use it. You use it to destroy, but it should be used to create. I don't know how either. We haven't learned yet.

git push

How I built an full-cache ORM

Kerman — Fri, 30 Jan 2026 10:06:58 +0000

Personal history

The core concepts of this ORM first appeared in 2008, when I had just started learning a new programming language called C# and needed a database. Of course, I had no intention of writing an ORM. I simply needed to store data and work with it. The most convenient approach was to map table columns to class fields and then work with the class logic.

At first, I manually unpacked data from a reader and then manually composed INSERT or UPDATE statements when it was time to persist an object. This was tedious, and I wanted to automate it. On top of that, annoying mistakes and typos would appear from time to time like sending the wrong field to the wrong place, or forgetting to add a field everywhere it interacted with the database, which led to “delayed” bugs. I decided to generate code directly from the database structure.

Much later, when I learned about the ORM concept, I discovered that this approach is called database-first, as opposed to code-first. When an application works with a database, the problem of keeping the application’s data model in sync with the database schema inevitably arises. This is a fundamental problem, and it hasn’t gone away over the years. There are exactly two options: either treat the database schema as the source of truth (which is what I did), or treat the code as the source of truth. In any case, one side has to be generated from the other.

I decided to parse the structure of MySQL tables and generate data classes for C#. In addition to the classes themselves, I generated structures responsible for materializing objects from a reader and composing INSERT/UPDATE commands. This was simpler and more reliable. I manually modified the database schema and ran the code generator. The generator fully rewrote the file with the class definitions, mapping MySQL data types to C# types. Thanks to partial classes, handwritten logic could live in a separate file, while only the accessors were subject to regeneration.

The next problem to solve was data synchronization between multiple clients connected to the same database. Today I know that the correct solution is to write an application server and route all data changes through it. Back then, that understanding didn’t exist. What did exist was MyISAM, which provided a per-table update timestamp out of the box. And that pushed me to use it.

The task was simple: when one client inserts or updates data, other clients should see those changes and reflect them. The solution was crude. Every 10 seconds, the client polled MySQL’s “meta table” that stored information about MyISAM tables. The last modification timestamp was compared to the previous value, and if it differed, the UI was told to redraw some list. Even if that list wasn’t the table itself but related entities, for example, employees.

And it worked perfectly until the data volume was small and the system was simple. Later it became obvious that rereading entire tables was, to put it mildly, a bad idea, especially as the data kept growing. A 10‑second update delay was also too long. Later there would also be the migration from MyISAM to InnoDB, but that came later. Even at that moment, it was clear this approach wouldn’t scale.

The solution was to fetch only changed data. That meant caching the data locally. I couldn’t think of anything smarter than keeping it in a Dictionary (later replaced by List for significant memory savings). This introduced constraints: each table had to start with an int ID column, which also had to be a primary key with auto_increment. New data could be fetched using the maximum ID, but what about updated rows?

I had to add a mandatory timestamp column to every table. Now, on a timer, the client checked the meta table and for changed tables ran a SELECT like WHERE ID > %maxId% OR Updated > %maxUpdated%. With traffic drastically reduced, it was possible to poll every second, which was quite acceptable.

Another problem surfaced. Before synchronization could begin, the data had to be cached. The issue appeared when views started receiving data that referenced other data which hadn’t been loaded yet. At first, this resulted in KeyNotFoundException, which I “solved” with what I later learned was simply the null object pattern.

Instead of querying the dictionary directly, I introduced a repository. If the repository couldn’t find an object with a given ID, it returned a “null object” — an empty instance of that type. That’s how I learned to stop worrying and love NULL: the null object allowed access to all fields without littering the code with checks. I could build dependency chains "order → customer → customer details" without worrying about nulls. They simply couldn’t exist; at worst, I’d get an empty string instead of a name.

It quickly became clear that sending an entire object for updates was a terrible idea. Two clients could modify different fields of the same object within the same second, and the second update would overwrite the first. Fields had to be sent individually but only the ones that actually changed.

Around this time, I encountered the ORM concept. I briefly explored Entity Framework and decided that I didn’t need any ORM at all.

Ironically, by that point I already had my own ORM — very specific, but sufficient for my needs. Still, I stubbornly believed that all this complexity wasn’t needed in real development. "No time to sharpen the saw; we need to saw." To be fair, the data access syntax in my ORM was much simpler than in EF. I had a static repository with IEnumerable support, which allowed using LINQ to Objects directly on the repository. EF required declaring a context.

Using the ORM felt as if "the database didn’t exist". That was the guiding principle of the system. I simply pulled data from the repository as much as I wanted, however I wanted. It was fast. Very fast. Insanely fast. Unsurprisingly so: the data was already in memory, there were no database queries and therefore no network latency. ID access was O(1). Conditional filtering was O(N). There was no N+1 problem. If I needed a join, well, I didn’t (sorry for the pun). The entity already referenced another existing entity. Adding an object meant adding it to the repository, and it would magically receive an ID (with the caveat that inserts were not instantaneous; they involved an INSERT followed by SELECT last_insert_id). Changing a field meant simply assigning a new value to it. That change propagated to all clients within the same second.

At this point, an attentive reader has probably already identified the fatal flaw of this ORM: big data. Data that takes a long time to load and consumes large amounts of RAM on the client machine. Using a caching container for such data is, to put it mildly, irrational. It’s far more reasonable to fetch only the required data using WHERE clauses.

For this purpose, I created a low-level class that couldn’t cache yet but already knew how to map data. Query parameters included a raw SQL filter like WHERE YEAR(Orders.Created) > 2012. The container assembled the full SELECT, fetched the data, and mapped it to class fields. Its IEnumerable nature almost begged for a yield return–based implementation, resulting in a fast, pipeline-style construct that streamed freshly read data into the business logic as it came from the reader.

After getting acquainted with EF, I really liked the idea of LINQ to DB: you write queries against the repository as if it were an IEnumerable, and internally it translates the query to SQL and returns the required objects. I honestly tried to dig into DbLinq and extract what I needed, but quickly got lost in the code. Writing my own translator turned out to be simpler—and that’s what I did.

The translator parsed expression trees and translated what it understood into SQL. It didn’t understand much: it could build simple WHERE clauses, ORDER BY (including DESC), and LIMIT. On the C# side, it supported Where, OrderBy/OrderByDescending, Take/Skip, and First/Last/FirstOrDefault/LastOrDefault. Its beauty was its size: very compact, literally two or three screens of code.

It also supported some very specific features, such as translating enums and application-specific types. For example, a query like Sql.Calculations.Where(c => c.State == CalculationState.New) became WHERE c.State = 1 in SQL. I cared a lot about code readability.

Architecture

This was already the fourth type of repository I had introduced into the system. All three previous ones shared roughly the same syntax. To avoid confusion, here are the repository types explicitly:

Table<T>: a low-level data access mechanism with mapping. Works with raw SQL but returns strongly typed objects.
CachedContainer<T>: a lazy repository. On first access, it loads all data from the table. On subsequent accesses, it checks data freshness by comparing last_updated. Ideal for tiny tables that rarely change and must be accessed quickly. Built on top of Table<T>.
TrackedContainer<T>: a “hot” repository. Loaded once at client startup and then kept in sync. The main workhorse of the system. Built on top of Table<T>.
LinqContainer<T>: a “cold” repository. Translates expression trees into SQL queries, fetches data, maps it to entities, and returns the result. Built on top of Table<T>.

The code generator regenerated the file with entity classes from scratch, even pulling comments from the database. It looked roughly like this:

public partial class Brand : sqlobject
{
    #region Private members

    /// <summary>;
    /// Customer's organization ID
    /// </summary>;
    private int customerID;

    /// <summary>;
    /// Brand category (Keywords)
    /// </summary>;
    private int categoryID = 0;

    /// <summary>;
    /// Is Luxury brand
    /// </summary>;
    private bool luxury;

    #endregion

    #region Properties

    /// <summary>;
    /// Customer's organization ID
    /// </summary>;
    public int CustomerID
    {
        get { return customerID; }
        set { if (customerID != value){ customerID = value; Update("CustomerID", value);}}
    }

    /// <summary>;
    /// Brand category (Keywords)
    /// </summary>;
    public int CategoryID
    {
        get { return categoryID; }
        set { if (categoryID != value){ categoryID = value; Update("CategoryID", value);}}
    }

    /// <summary>;
    /// Is Luxury brand
    /// </summary>;
    public bool Luxury
    {
        get { return luxury; }
        set { if (luxury != value){ luxury = value; Update("Luxury", value);}}
    }

    #endregion

    #region Methods

    public override bool Download(FieldReader fieldReader)
    {
        bool changed = false;
        if (fieldReader.Read(ref customerID, "CustomerID")) { changed = true; OnPropertyChanged("CustomerID"); }
        if (fieldReader.Read(ref categoryID, "CategoryID")) { changed = true; OnPropertyChanged("CategoryID"); }
        if (fieldReader.Read(ref luxury, "Luxury")) { changed = true; OnPropertyChanged("Luxury"); }
        return changed;
    }

    public Brand CopySqlFields()
    {
        var copy = new Brand();
        copy.Name = Name;
        copy.CustomerID = CustomerID;
        copy.CategoryID = CategoryID;
        copy.Luxury = Luxury;
        return copy;
    }

    #endregion
}

The Download method and Read calls include built-in INotifyPropertyChanged support, making it possible to bind entities directly to the UI grid, for example.

protected void Update(string column, object value)
{
    if (Updates == null) Updates = new Dictionary<string, object>();
    Updates[column] = value;
    OnPropertyChanged(column);
    sql.ItemChanged(GetType(), this);
}

The Update method also supports INotifyPropertyChanged, collecting changed fields into an untyped dictionary and pushing updates to the database after 30 ms. Strong typing isn’t critical here because the connector’s AddParameter method accepts object anyway.

The FieldReader is straightforward: overloaded Read methods for each supported type.

public class FieldReader
{
    public HashSet<string> Fields = new HashSet<string>();
    private MySqlDataReader dataReader;
    public FieldReader(MySqlDataReader dataReader)
    {
        this.dataReader = dataReader;
        for (int i = 0; i < dataReader.FieldCount; i++) Fields.Add(dataReader.GetName(i));
    }

    public int GetId()
    {
        if (Fields.Contains("ID"))  return dataReader.GetInt32("ID");
        return 0;
    }

    public bool Read(ref int field, string column)
    {
        if (!Fields.Contains(column)) return false;
        var val = dataReader.GetInt32(column);
        if (field == val) return false;
        field = val;
        return true;
    }

    public bool Read(ref int? field, string column)
    {
        if (!Fields.Contains(column)) return false;
        int index = dataReader.GetOrdinal(column);

        int? val = null;
        if (!dataReader.IsDBNull(index))
            val = dataReader.GetInt32(index);

        if (field == val) return false;
        field = val;
        return true;
    }

    public bool Read(ref bool field, string column)
    {
        if (!Fields.Contains(column)) return false;
        var val = dataReader.GetBoolean(column);
        if (field == val) return false;
        field = val;
        return true;
    }

    public bool Read(ref DateTime field, string column)
    {
        if (!Fields.Contains(column)) return false;
        int index = dataReader.GetOrdinal(column);

        //nullable DateTime converting to minvalue
        DateTime val = DateTime.MinValue;
        if (!dataReader.IsDBNull(index))
            val = dataReader.GetDateTime(column);
        if (field == val) return false;
        field = val;
        return true;
    }

    public bool Read(ref string field, string column)
    {
        if (!Fields.Contains(column)) return false;
        var val = dataReader.GetString(column);
        if (field == val) return false;
        field = string.Intern(val);
        return true;
    }

    public bool Read(ref Guid field, string column)
    {
        if (!Fields.Contains(column)) return false;
        var val = dataReader.GetGuid(column);
        if (field == val) return false;
        field = val;
        return true;
    }

    public bool Read(ref decimal field, string column)
    {
        if (!Fields.Contains(column)) return false;
        var val = dataReader.GetDecimal(column);
        if (field == val) return false;
        field = val;
        return true;
    }

    public bool Read(ref Money field, string column)
    {
        if (!Fields.Contains(column)) return false;
        var val = Money.FromDecimal(dataReader.GetDecimal(column));
        if (field == val) return false;
        field = val;
        return true;
    }

    public bool Read(ref float field, string column)
    {
        if (!Fields.Contains(column)) return false;
        var val = dataReader.GetFloat(column);
        if (Math.Abs(field - val) &lt; float.Epsilon) return false;
        field = val;
        return true;
    }

    public bool Read(ref long field, string column)
    {
        if (!Fields.Contains(column)) return false;
        var val = dataReader.GetInt64(column);
        if (field == val) return false;
        field = val;
        return true;
    }

    public bool Read(ref long? field, string column)
    {
        if (!Fields.Contains(column)) return false;
        int index = dataReader.GetOrdinal(column);

        long? val = null;
        if (!dataReader.IsDBNull(index))
            val = dataReader.GetInt64(index);

        if (field == val) return false;
        field = val;
        return true;
    }
}

One notable detail is that FieldReader tolerates missing fields. Dropping a column from a table won’t crash all connected clients.

The query translator:

public class QueryBuilder
{
    private readonly string tableName;
    private string where = "";
    private string orderby = "";
    private string orderbydesc = "";
    private int limit = 0;
    private string select = "*";
    public bool DefaultNull = false;
    public string Select =>; select;

    public string Conditions
    {
        get
        {
            var cond = new List<string>();
            if (where != "") cond.Add("WHERE " + where);
            if (orderby != "") cond.Add("ORDER BY " + orderby);
            if (orderbydesc != "") cond.Add($"ORDER BY {orderbydesc} DESC");
            if (limit > 0) cond.Add("LIMIT " + limit);
            return string.Join(" ", cond);
        }
    }

    public QueryBuilder(string tableName)
    {
        this.tableName = tableName;
    }

    public void AddExpression(Expression expression)
    {
        var method = expression as MethodCallExpression;
        var name = method.Method.Name;
        var args = method.Arguments;
        ParseCallExpression(args, name);
    }


    private void AddExpression(ref string expr, ReadOnlyCollection<Expression> args)
    {
        if (!args.Any()) return;

        var arg = args.Last();

        if (!(arg is UnaryExpression lambda)) return;
        if (arg.NodeType != ExpressionType.Quote) return;

        var toadd = GetSqlExpression(lambda.Operand);
        if (expr == "") expr = toadd;
        else expr = expr + " AND " + toadd;
    }

    private void ParseCallExpression(ReadOnlyCollection<Expression> args, string name)
    {
        switch (name)
        {
            case "Where":
                AddExpression(ref where, args);
                return;
            case "OrderBy":
                AddExpression(ref orderby, args);
                return;
            case "OrderByDescending":
                AddExpression(ref orderbydesc, args);
                return;
            case "First":
                AddExpression(ref where, args);
                limit = 1;
                DefaultNull = false;
                return;
            case "FirstOrDefault":
                AddExpression(ref where, args);
                limit = 1;
                DefaultNull = true;
                return;
            case "LastOrDefault":
                AddExpression(ref where, args);
                limit = 1;
                DefaultNull = true;
                return;
            default:
                throw new NotImplementedException(name);
        }
    }

    private string GetSqlExpression(Expression expr)
    {
        if (expr is LambdaExpression predicate) return GetSqlExpression(predicate.Body);
        if (expr is BinaryExpression bin)
        {
            var left = GetSqlExpression(bin.Left);
            var right = GetSqlExpression(bin.Right);

            if (bin.NodeType == ExpressionType.AndAlso) return left + " AND " + right;
            if (bin.NodeType == ExpressionType.OrElse) return left + " OR " + right;
            if (bin.NodeType == ExpressionType.Equal) return left + " = " + right;
            if (bin.NodeType == ExpressionType.GreaterThan) return left + " < " + right;

            throw new NotImplementedException(bin.NodeType.ToString());
        }

        if (expr is UnaryExpression un)
        {
            if (un.NodeType == ExpressionType.Not)
            {
                return "NOT " + GetSqlExpression(un.Operand);
            }
            if (un.NodeType == ExpressionType.Convert)
                return GetSqlExpression(un.Operand);


            throw new NotImplementedException(un.NodeType.ToString());
        }

        if (expr is MemberExpression ex)
        {
            if (ex.Expression.NodeType == ExpressionType.Parameter)
                return tableName + ".`" + ex.Member.Name + "`";

            var objectMember = Expression.Convert(ex, typeof(object));
            var getterLambda = Expression.Lambda<Func<object>>(objectMember);
            var getter = getterLambda.Compile();
            var value = getter();
            return GetValue(value);
        }

        if (expr is ConstantExpression c)
        {
            return GetValue(c.Value);
        }

        throw new NotImplementedException(expr.ToString());
    }

    private string GetValue(object obj)
    {
        if (obj is string s)  return "\"" + s + "\"";
        if (obj is int i) return i.ToString();
        if (obj is Enum) return ((int)obj).ToString();
        if (obj is DateTime dt) return $"'{dt:G}'";
        throw new NotImplementedException("Unsupported argument type " + obj.GetType());
    }
}

The query translator implementation follows, along with LinqContainer and LinqProvider, which provide IQueryable<T> support. Their role is fairly straightforward.

public class LinqContainer<T> : TableContainer<T>, IQueryable<T> where T : sqlobject, new()
{
    private LinqProvider<T> provider;

    public void Add(T obj)
    {
        obj.Upload(table.SchemaTableName);
        subscriber.Launch();
    }

    public LinqContainer(string tableName, string schemaName = sql.MainSchema) : base(tableName, schemaName)
    {
        provider = new LinqProvider<T>(table);
    }

    public IEnumerator<T> GetEnumerator()
    {
        return provider.GetEnumerator();
    }

    IEnumerator IEnumerable.GetEnumerator()
    {
        return provider.GetEnumerator();
    }

    public Expression Expression => provider.Expression;
    public Type ElementType => typeof(T);
    public IQueryProvider Provider => provider;
}

public class LinqProvider<T> : IQueryProvider, IOrderedQueryable<T>
{
    private readonly SqlTable table;
    private List<Expression> expressions = new List<Expression>();

    public LinqProvider(SqlTable table)
    {
        this.table = table;
    }

    public IQueryable CreateQuery(Expression expression)
    {
        var type = expression.Type;
        if (!type.IsGenericType)
            throw new ArgumentException($"S0066: Don't know how to handle non-generic type '{type}'");
        var genericType = type.GetGenericTypeDefinition();
        if (genericType == typeof(IQueryable<>) || genericType == typeof(IOrderedQueryable<>))
            type = type.GetGenericArguments()[0];
        else throw new ArgumentException($"S0068: Don't know how to handle type '{type}'");
        return null;
    }

    public IQueryable<TElement> CreateQuery<TElement>(Expression expression)
    {
        var provider = new LinqProvider<TElement>(table);
        provider.expressions = new List<Expression>(expressions);
        provider.expressions.Add(expression);
        return provider;
    }

    public object Execute(Expression expression)
    {
        throw new NotImplementedException();
    }

    public TResult Execute<TResult>(Expression expression)
    {
        var returnType = typeof(TResult);
        expressions.Add(expression);
        var builder = new QueryBuilder(table.TableName);
        foreach (var expr in expressions)
        {
            builder.AddExpression(expr);
        }
        expressions.Clear();

        if (returnType == typeof(IEnumerable<T>))
        {
            var list = GetList<T>(builder.Select, builder.Conditions);
            return (TResult) Convert.ChangeType(list, returnType);
        }

        if (returnType == typeof(T))
        {
            var list = GetList<T>(builder.Select, builder.Conditions);
            if (list.Count == 0)
            {
                if (builder.DefaultNull) return default;
                throw new InvalidOperationException();
            }
            return (TResult) Convert.ChangeType(list[0], returnType);
        }

        throw new NotImplementedException(returnType.ToString());
    }

    private List<TResult> GetList<TResult>(string query, string conditions)
    {
        var list = new List<TResult>();
        FieldReader fr = null;
        foreach (var dr in table.Select(query, conditions))
        {
            if (fr == null) fr = new FieldReader(dr);
            TResult obj = Activator.CreateInstance<TResult>();
            if (obj is sqlobject sqlobj)
            {
                sqlobj.FromReader(fr);
                sqlobj.Download(fr);
            }
            list.Add(obj);
        }
        return list;
    }

    public Expression Expression => Expression.Constant(this);

    public Type ElementType => typeof(T);

    public IQueryProvider Provider => this;

    public IEnumerator<T> GetEnumerator()
    {
        var builder = new QueryBuilder(table.TableName);
        foreach (var expr in expressions)
            builder.AddExpression(expr);

        var list = GetList<T>(builder.Select, builder.Conditions);
        return list.GetEnumerator();
    }

    IEnumerator IEnumerable.GetEnumerator()
    {
        return GetEnumerator();
    }
}

Why all of this

The query mechanism based on IEnumerable and IQueryable is intentionally concise and expressive. Conditional queries do not mix application layers, which significantly reduces cognitive load when reading the code. This is a property shared by almost all ORMs.

In my case, the vast majority of repositories were TrackedContainers. Only the heaviest tables used LinqContainer. From a syntax perspective, however, they were almost indistinguishable. I could change the container type at will and get a working application with different runtime behavior.

Of course, there were nuances. The limitations of LINQ did not allow using business-logic methods as query predicates. Even EF can’t do that—only direct comparisons are supported. With IEnumerable<T>, however, this was possible.

The full-cache ORM concept itself enables persistent objects. This means that once you fetch a set of objects from a repository, you don’t get a copy of the data—you get a copy that carefully imitates the original. You can subscribe to PropertyChanged on an object and receive notifications about changes made elsewhere in the system or even in another client application. For the same ID, TrackedContainer always returned a reference to the same object instance.

Conclusion

As an ORM, this system stopped evolving after LINQ support was added in 2014. That doesn’t mean it died; it means its capabilities were sufficient for further work. The ORM itself did not evolve, but the ERP built on top of it certainly did. It is still running today, with real users—around 100–150 concurrent users. It is used for data collection, analytics, forecasting, and everything else ERP systems are generally used for.

It was an interesting experience of building an ORM that I never planned to build—and even actively denied building. Like a true bicycle builder, I started from the wrong end. While real ORM authors started with queries and then added caching, I started with full caching and only later added queries.

The system looks naive and wrong. I know that. But it works. And it does exactly what it was required to do.

Would I build something like this today? Probably not. I would rather extend EF with proper tracking.

Would I rewrite that system on top of EF? Definitely not. It is good in its own way.

What it always lacked was a separate application for model editing and data synchronization. I had to modify the test database and then apply the exact same changes to production manually. I also had to write my own database schema parser for code generation. If OrmFactory had existed back then, it would have been much simpler and far more convenient.

Why would you ever use an ORM?

Kerman — Wed, 03 Dec 2025 11:50:46 +0000

Software development is always a search for balance between multiple aspects: development speed (how fast you ship new features), application performance, memory consumption, UI quality, and the cleanliness of your business logic.

In most cases, development speed is more important than performance or memory consumption. Performance is often "good enough" memory usage is often "acceptable" but development speed directly affects business profitability. There is never "too much" development speed. It determines how much money the business will spend on building the product and how long it will stay under the pressure of risk. If you are targeting a competitive market and your rivals can launch earlier, then nothing is more critical.

Of course, an application that barely moves or consumes absurd amounts of memory won’t survive competition. But if you compare speeding up an app by 20% with saving two or three months of development time, the choice is obvious. Users may not notice the extra 20% speed, but the budget hole will definitely be noticed.

How an ORM speeds up development

ORM is a tool designed to save development time. But how exactly?

First, an ORM makes your code shorter. It hides the tons of boilerplate required to move values between table columns and class fields. This also ensures type safety: the type of a class field always matches the database column type.

This applies primarily to statically typed languages, but IDE completions work everywhere. Autocomplete improves both developer experience and correctness, which also means faster work.

Shorter code is quicker to write and quicker to read. The latter matters even more in large projects, where the limiting factor is the cognitive load of the human brain. Proper layering and clean, well-scoped functions are an art, but hiding technical details behind abstractions helps keep code understandable.

ORMs let you work at a higher level of abstraction. They handle fields and expose objects. You can take a common base query and modify it for multiple specific cases using polymorphism. You can add conditions dynamically depending on user input. Doing the same with raw SQL is significantly harder.

ORMs are less error-prone. When writing SQL by hand, it’s easy to make a mistake in one of thirty fields. An ORM won’t make that mistake. Moreover, it will automatically update all queries when you add or rename fields. It won’t forget to update a reference. Over long development cycles, this eliminates an entire class of human-factor errors and saves huge amounts of debugging time.

ORMs also greatly simplify data refactoring. This is a very underrated feature of mappers. Cleaning up and reorganizing the schema is dramatically easier with an ORM than without one. Hard metrics are difficult to define, but schema refactoring can easily accelerate long-term development by an order of magnitude.

Yes, a new abstraction layer adds some entry complexity. If your project has ten tables that rarely change, you probably don’t need an ORM at all. ORMs exist to manage high complexity, and small projects simply don’t have that complexity.

Impact on performance

Earlier, I said that development is a search for compromise. Does using an ORM mean losing performance or increasing memory usage? Not necessarily. Let’s look at it closer.

Yes, an ORM introduces some overhead for building queries and mapping data. But compared to database I/O, this overhead is negligible. What matters more is that shorter code and easier algorithmic optimization often make ORM-based logic faster than raw SQL in long-term development. Sure, raw SQL can be optimized. But it’s harder to see the full picture, and everyone is afraid to touch something that works — it might break. So developers avoid refactoring raw SQL.

This leads to a paradox: raw SQL may run slightly faster at the moment it is written, but after many iterations of development, the ORM version often ends up significantly faster due to incremental cleanups and safer refactoring.

Sometimes people argue that ORMs make it too easy to generate excessive queries, especially when used by junior developers who don’t understand SQL. But the truth is simple: to use an ORM properly, you must know SQL. You must understand what SQL is generated by your language-level expressions. An ORM is not a replacement for SQL. It is an abstraction layer on top of SQL, not a substitute for it.

Memory consumption

Memory consumption isn’t straightforward either.

I’ve seen developers load entire tables into DataTable objects and then work with them as if they were Excel sheets. In such structures, an Int32 may occupy 8 bytes on the stack plus 24 bytes on the heap (CLR, x64). ORMs store data in typed fields, which reduces memory usage drastically.

Database query results are inherently flat tables. Imagine a table with 100+ columns (e.g., orders) joined one-to-many with a table of 5 fields (positions). If you store the result “as is,” every position record duplicates all 100+ fields from the left table. Memory waste becomes ten-fold or even hundred-fold. A good ORM groups child rows under a single parent instance instead of duplicating all the data.

Schema Synchronization

The first task of any ORM is to keep the database schema and application objects in sync. This is the essence of mapping: loading table columns into class fields and writing them back. To do this correctly, the ORM must take the “original” schema definition at compile time. That definition can come from the database (db-first), from code (code-first), or from a separate model (model-first).

Code-first projects the schema from code into the database. It’s convenient when you have multiple environments, but it breaks down when multiple independent services try to reshape the database to suit themselves. Synchronization becomes complex because it requires loading the existing schema, comparing it correctly, and generating intricate DDL. This approach is beyond the scope of this article, so we won’t go into it here.

DB-first and model-first rely on code generation of entity classes. This is much simpler: load the schema from the database (or from the model file) and regenerate the entity files.

In practice, schema synchronization always has project-specific requirements. Often you need to extend generation for your own rules, but built-in ORM generators are usually closed and not easily customizable. Maybe you want to import database comments into entity files to keep unified documentation. Maybe you use relationships with incompatible field types, or many-to-many links through text columns that can’t be expressed as foreign keys. Maybe your enums require custom mapping logic.

This rigidity is a common and justified criticism of ORMs. I solved this problem by using open-source generators. You can take an MIT-licensed generator and modify it for your project’s needs. This is far easier than writing a generator from scratch, because OrmFactory takes care of most of the heavy lifting. It works directly with the database and can export the schema into your project. Its philosophy is simple: it handles schema design and synchronization, leaving the ORM to do what it does best — mapping.

It’s Time to Move Your System to an ORM

Kerman — Fri, 21 Nov 2025 16:56:08 +0000

It should have been done long ago. Right at the moment you realized you’d be working with a database. Sure, adopting an ORM now is harder than doing it from day one, but it’s still not too late.

Today I’m going to push my subjective, one-sided, and only correct opinion about why you need an ORM.

There are contraindications for introducing an ORM into your project. Consult your common sense before applying.

That amazing high you get from being useful

Yes, it feels amazing. You started a project the business has needed for years. Not a pet project, not a coursework exercise, an actual business project, funded, real, important. One that finally fixes the broken processes people have been suffering through for ages. You decided to help real humans who struggle with imperfect tools every single day.

We, as engineers, really are wizards. We can fix things. Especially when our eyes shine and our hands itch to make something better. Spending a day writing code so dozens of people save time every day? Every single day? Even when we’ve moved on to completely different things, and they’ll still be saving time. And enjoying it.

Relax, this is not the part where I “bring you back to reality.” We really can do this. That’s why we get paid well. That’s why we enjoy this work. We genuinely like building useful stuff. It feels good to be useful, to be valued. Dopamine, serotonin, whatever, I don’t know the biology behind it, I just threw in a couple of smart words.

It’s a powerful feeling when you take on something and it works. You deliver real value. You’re saving the whole business, the hero in shining armor. People tell you how much better things have become. It warms you. It motivates you.

Well, almost. Because then comes the "If only we could also fix this. And maybe automate that. And we’ve still got this Excel thing over here…"
Once the business gets a taste of ~~blood~~ optimization, it wants more. More. Moar!

That’s it. From this moment you’re officially in the hamster wheel. Solve the hard stuff, and they’ll want the unimaginable. Solve the unimaginable, and they’ll want the impossible. Business has no stop button. Your application has no built-in ceiling. There’s only you, the business, and the system you’re building.

Complexity

With every new feature, the system gets more complex. Every time you add something new, you must consider whether it breaks something old. Keeping all the nuances in your head gets harder and harder.

Meanwhile, the business is getting hooked. They can see your team handling the complex, and now they crave the even more complex. With every cycle, your team’s workload and the system’s complexity grow. The low base effect is long gone, and every new feature now comes with sweat, if not blood.

Complexity is your enemy. Well… ours too, if I’m honest. It’s also the business’s enemy, though it’s nearly impossible to explain this to them. They’ve seen how transformative your system can be, and they expect the magic to continue. You can try explaining, but good luck.

It’s the business’s enemy, because (surprise!) it’s their problem too. Explaining this to them is nearly impossible. They’ve seen with their own eyes how transformative your system can be, and now they expect the magic to continue. You can try but good luck. I won’t offer any advice here, you’re on your own.

You’re hooked on usefulness. The business is hooked too. You both crave the next dose. And then complexity walks in and ruins everything.

I’m not going to tell you how to handle it all. But I will tell you how to reduce your system’s complexity a bit by introducing an ORM, so you can extend your dopamine high, addicts.

Data

The first question in any system: how do we store data? The answer is “database.” Really, what else? Which one? Doesn’t matter, just something that stores data. You’re not going to keep it in Excel, right? So you pick {vendor}SQL.

You chose a relational database. Not because you thought about the word “relational”. You probably didn’t even consider what that meant. But that’s what you picked.

A note for those who chose NoSQL: you’ll regret it. You’ll rewrite it all into an RDBMS. And once you finish rewriting it, you’ll finally understand what NoSQL was actually for. And then migrate part of it to Mongo. Or whatever is fashionable by then.

So, you have a relational database, and you’re using an object-oriented language to work with it. Feel the contradiction forming?

Long story short: object-oriented data structures nest objects inside objects, while relational ones reference things.

I used to think and preach that ORM is exactly this: a bridge between relational tables and object-oriented structures. And yes… well, almost. The problem is unsolvable the general case. But for your specific case? Sure, you can fetch rows and map fields manually. If you couldn’t, what are you even doing here?

Map data once is easy. Keeping it consistent later is the real problem. And even harder is being confident it all stays consistent.

This is where an ORM comes into play.

ORM

An ORM ensures you have a single model for your data, both in the database and in your code. Class fields correspond to table columns. Casting happens automagically. You work with objects as if they weren’t pulled from a database at all, just regular in-memory objects.

ORM is needed so data and application form a single whole. So there’s no difference in code between an object from a dictionary and an object from a repository. Because you, dear friend, need to manage complexity. Less complexity → easier features → more dopamine. Remember?

An ORM is needed so you stop manually juggling fields. Seriously. Stop. Enough. Database fields are database fields, your team works on business logic, which isn’t about individual fields. Sure, it’s not limited to objects either — but let’s at least solve the field problem first.

With an ORM, you can forget about mapping errors. As your system grows, the ORM guarantees that class fields match table columns. Always. You change the database schema and immediately the code that relied on removed fields breaks. Fair enough: just follow the compilation errors and fix the logic. See? Stop shuffling values around by hand. Focus on the logic. An ORM handles this far faster, more reliably, and far more consistently than your biological neural network ever will.

Your code becomes shorter and clearer. Instead of large, fragile, unreliable chunks where SQL in quotes is sent to a command and then you manually pull fields out of a reader and stuff them into objects, you get a short, predictable ORM call. And yes, that hand-written, quote-wrapped SQL will eventually break at runtime gifting you a “pleasant” debugging session long after you’ve forgotten what you were even working on. Do you really want to burn your cognitive resources on that?

Don’t try to work with an ORM without knowing SQL. And don’t involve people who don’t know SQL in ORM work. An ORM is not a replacement for SQL. It works on top of it, adding layers of abstraction, so you need to understand how an ORM query gets translated into SQL. Otherwise, you’ll end up with terrible, slow code and I’ll get blamed for making projects worse with the ORM.

Stop Writing Business Logic Inside the Database

Stop. Really. You simply cannot evolve a complex system inside your database’s stored-procedure language. No matter how skilled you are, you’ll always be working with data, not domain concepts. You’ll always be one or two abstraction levels below those who work with objects.

The fundamental problem with PL/SQL-type languages is that they’re essentially write-only. You won’t notice at first, simple things look innocent. It’s the boiling frog effect. Complexity grows, it gets in the way, and within the database that pain arrives much sooner.

Work in a general-purpose language. As complexity grows, you’ll have more tools to manage it: interfaces, inheritance, encapsulation, libraries from GitHub.

If you write business logic in the database using a general-purpose language, then answer honestly: how are you going to package and integrate it with your main codebase?

Stop writing SQL by hand. It’s faster in the moment, but once your system grows even slightly, you’ll have to update these queries constantly. Every time you add a field, you’ll update your fetch code. Every. Single. Time.

I’m not saying you should completely give up SQL. Sometimes you still need to work with raw data, because doing it through the ORM would be worse. But these are exceptions, not the rule.

Sure, you can automate this. Write a schema synchronizer, generate code from classes, map types. That’s ORM. A simple one, crude and tiny, but an ORM nonetheless. Maybe that’s fine. Maybe that’s the right path.

Either way, it’s time to move your system to an ORM.

Ready to cut through complexity? OrmFactory helps you integrate ORM into your project quickly, safely, and reliably. Generate models, manage database changes, and focus on business logic, not field mapping. Less manual work, fewer headaches, more control. Give your team the dopamine tool they deserve.

Why Model-First and where the Truth lives

Kerman — Tue, 14 Oct 2025 12:25:12 +0000

Relational databases have one minor shortcoming. They do not render tabular data on the user’s screen. On one hand, that’s not really a problem. A database does database things and doesn’t go into UI, where not welcome. On the other hand you must ferry data through another language, sometimes two or three in a web stack. And don’t forget the query language itself. It’s a language too.

All languages are tools to reduce digital chaos. They give you ways to collect scattered fields into one place and even name the resulting structure. In OOP languages that utility is part of the paradigm. Most server-side stacks between the DB and the UI are object oriented. Naturally developers reach for structural language tools to pack table fields into a class. That’s how DTOs, entities, POJOs, and other wrappers appear.

It doesn’t sound like a big deal. We just build the structure in our favorite programming language, make it match the database, and stack our little blocks together, hoping they’ll spell “happiness.” It works for a while. Then the structures in code and in the database start to drift apart. And if they don’t, poke your project with a stick. It might be dead. A dead bird doesn’t sing, and a dead project doesn’t change its structure.

It’s not that we haven’t learned how to solve this problem. We do, and quite well. For example, I once heard this approach: just make every change carefully in both the database and the code at the same time, and never make a mistake. Then nothing will drift out of sync. You laughed too, right?

Before we move on to practical solutions, I want to emphasize that this is a truly fundamental problem. It does not depend on the specific database, language, or framework. You can be the most advanced architect, the most pedantic senior, but if you work with a database, this problem will be there for you.

I am talking about relational data. Document databases have their own toys to play with. Schema drift there takes on truly twisted shapes. Objects in a collection gain fields over time. Consistency rules vary by ID ranges. Code accumulates workarounds and multiple deserializers for different vintage records because the format changed. And to top it off, teams sprinkle in on-the-fly migrations and versioned transformations.

Relational databases behave differently. A schema change applies to all rows at once. If you add a column it appears for the earliest rows too, which forces compatibility with the new structure. Sometimes you still run a migration job to reshape historical data. But that single-version model spares you much of the multiversion headache. I treat this as static typing for data: it forces structure discipline. So let’s get back to relational systems.

You have probably seen the interview question: “What’s the difference between code-first and db-first? Pros and cons?” It’s an interview favorite. Here’s my answer.

Approach	Advantage	Disadvantage
Code-first	Makes DB structure follow code	Makes DB structure follow code
DB-first	Makes code follow DB structure	Makes code follow DB structure

Just giving you a free hint.

I used to sit firmly in the DB-first camp. Data feels primary to me. Intuitively, it was weird to let a migration tool “poke” the database. What if someone accidentally deleted or renamed a field in the code? Will the column be dropped from the DB?

If code generation from DB goes wrong you regenerate, fix, or restore from Git. When you generate DB structure from code you touch actual data. Data is valuable. You cannot restore yesterday’s user contributions from Git. Backups are older. Mirrors get overwritten. Data loss hurts.

Databases come first for another reason. In new projects data often already exists. Maybe not as a clean SQL schema but as Excel files or CSV dumps. You design the DB structure and then write code around it. You treat schema carefully because “garbage in, garbage out”. Changing DB structure is harder than changing code because data lives in the DB.

I used to think of code first as a kind of training wheels approach. Something you start with when you’re just getting familiar with databases and building your first pet projects. I believed that sooner or later it would cause trouble once the system grew and the data, the data people actually worked hard to create, became valuable.

But there is one thing code first really gets right. It lives comfortably in Git, which means it branches by feature, merges back cleanly, and fits perfectly into existing developer workflows. That’s definitely a plus.

Both approaches work and have a place. So where’s the problem? Why the heated debates? Why do I treat it as a false dichotomy?

We must understand what these approaches actually do. Code generation and DB sync are tools. But each approach also carries an ideology bigger than hitting a script at startup.

It comes down to the source of the Truth.

Yes. That is the only real difference. One approach declares the Truth lives in code. The other declares the Truth lives in the database. Not “truth”. The Truth. When structures drift, both sides can be “correct”. The database doesn’t lie. Code doesn’t lie. The mismatch is a coordination problem.

If you prefer DB truth you assume code is the heretic that must be watched so it does not stray from the righteous path. If you see the Truth in code, you expect the database to follow its scripture. Either way, someone plays the role of the high priest.

But my beloved DB-first fails when you have multiple environments. Production, staging, dev, CI, feature locals, and so on. Each environment can claim it holds the Truth. Code-first has a symmetric flaw. It fails when multiple services share a single database. When multiple services run across multiple environments, good luck keeping anything consistent.

It’s not that we haven’t learned how to deal with these problems. We do, and quite well. As the saying goes, if a paradigm doesn’t work, you just haven’t added enough dirty hacks yet. In the db-first world, that means complex environment synchronizers, migration histories, and a lot more. Not exactly simple.

The debate between code-first and db-first supporters is fascinating and interesting. But third option people forget exists. Pull the source of truth out of both places and place it in a separate entity. Not code. Not DB. Something else.

That is the model-first approach.

Think of it like relational modeling. For 1:N relationships the referencing ID goes in the “many” table. For M:N you create a join table. Separated. Similarly, to avoid the coordination problems above you separate the authoritative definition of structure into a standalone artifact. That artifact must be language and framework agnostic. Then multiple environments and multiple services can reference the same model without arguing about who is “right.”

Some .NET users recall older Entity Framework flavors with a model-first workflow using .edmx files. That is model-first in spirit. But the cake is a lie. That tooling lived inside Visual Studio. The same Visual Studio that expired on macOS a year ago and never arrived on Linux. What if another project needs the same model? What if you want to use Dapper, a custom mapper, or a Java service that reads the same tables? What if a Django team touches the same DB? The .edmx model is not a shared contract. It is glued to a single stack.

Even if all your services are written in C# with EF, there is still no "galvanic decoupling" between the model and the code structure. All projects using this model are forced to include the full set of entities, even though they don’t need most of them.

A real model-first system must be independent of language and framework. Tools must be cross-platform. That’s the only way to share it across teams. The model must be a written contract of how data is shaped. Put it in Git. Version it. Diff it. Branch it. Merge it. Discuss it in PRs. Share it in meetings. That contract is the Truth you can point to.

Three years ago, I was looking for tools that would let teams work with a model without pain or suffering.

aaaand nothing

The paradigm existed, but the tools did not. As they say, the right tool simply wasn’t there. I started to understand why this approach wasn’t popular.

The closest match to my requirements was a piece of German software, but it was mostly geared toward ER diagrams rather than serious projects. I wanted more.

By the way, the software was quite expensive. Around $250 per developer per year, and it’s even more expensive now. The free version couldn’t handle model files. Just the entry ticket alone kills the model-first approach. And there’s nothing better. Please invent the wheel yourself. But make sure the GUI is there, RDBMS ideology is fully supported with all its nuances, database structure synchronization is advanced, and code generation works. Even at first glance, it doesn’t look simple.

Two years ago I started writing a database model editor. Not another quick ER toy. I wanted a tool that focuses on real project workflows. I wanted language-agnostic models, strong support for RDBMS nuances, advanced DB synchronization, and code generators that do not lock your choice of mapper or framework. It’s really simple. I could prototype something in a couple of months, isn’t it? Slightly more complex than an AI-powered everything startup, but less profitable.

Prototyping was not trivial. What looked like a short project exposed a pile of subtle issues. After two years I reached the core ideology and a usable product. I call the result OrmFactory. The initial milestone is an MVP suitable for real development. I’m looking for advanced developers to try it in real projects and provide feedback to improve the tool.

A useful example from recent work is a feature I call "Named Rows". Named Rows bring semantically meaningful table data (not just structure), into the code generator. You can reference specific table rows by name in generated code. This solves a family of problems about environment differences and language differences. It also addresses the psychological hurdle: “Can I trust a third-party tool to change my DB safely?” My implementation includes a galvanic decoupling between the authoritative model and the code artifacts that represent it. That decoupling reduces surprise for DB admins and developers across stacks.

The product story deserves a separate post. Today my aim was to argue for model-first as a sane alternative. I want model-first to be accessible, not a gated feature of expensive vendor tools. That is the goal behind OrmFactory.

May the Truth be with you.