What Is an ORM?

Your application thinks in objects: an Employee with a name and a salary. Your database thinks in rows and columns. An object-relational mapper sits between them and translates.

Without one, you write SQL by hand, read each column out of a result, and construct objects yourself. It works, and it is a great deal of repetitive code that has to change every time a column does.

List<Employee> employees = new();

using SqlConnection connection = new(connectionString);
await connection.OpenAsync();

using SqlCommand command = new(
    "SELECT Id, Name, Role, AnnualSalary FROM Employees WHERE Role = @role",
    connection);
command.Parameters.AddWithValue("@role", "Engineer");

using SqlDataReader reader = await command.ExecuteReaderAsync();

while (await reader.ReadAsync())
{
    employees.Add(new Employee
    {
        Id = reader.GetInt32(0),
        Name = reader.GetString(1),
        Role = reader.GetString(2),
        AnnualSalary = reader.GetDecimal(3)
    });
}

• Correct, and entirely mechanical. Note that the column positions 0 to 3 are tied to the order in the SELECT — reorder the query and this breaks silently.
• Every table needs its own version of this, and every schema change means revisiting it.

List<Employee> employees = await context.Employees
    .Where(e => e.Role == "Engineer")
    .ToListAsync();

• EF Core generates the SQL, runs it, and builds the objects.
• The query is written in C#, so renaming the Role property updates this automatically and misspelling it fails to compile rather than at run time.

The diagram shows why the abstraction leaks. Your LINQ query is translated into SQL, sent over a network connection, executed by the database, and the results are materialised back into objects. Each of those stages has a cost, and the round trip is usually the expensive one.

This is why a query returning ten thousand rows to count them is slower than asking the database for the count — and why knowing what SQL you generated is not optional detail.