Why should you care?

Tables use foreign keys and joins; ShopNest checkout code thinks in Order with a list of OrderItems. The ORM removes boilerplate mapping code on every query.

See it live — copy this example

Paste into a .NET project with EF Core packages, then run with LocalDB/SQL Server (dotnet ef / dotnet run).

var item = new OrderItem { ProductId = 10, Quantity = 2, UnitPrice = 499 };
_context.OrderItems.Add(item);
await _context.SaveChangesAsync();
// ORM emits: INSERT INTO OrderItems (ProductId, Quantity, UnitPrice) VALUES (10, 2, 499)

What happened?

• Add puts the entity in EF's change tracker.
• SaveChangesAsync builds and executes INSERT.
• You worked with objects; the ORM handled SQL dialect details.

Practice next

1. Draw two columns: "C# OrderItem object" and "OrderItems table" with matching fields.
2. Say aloud what SQL you expect before calling SaveChangesAsync.
3. Compare one hand-written INSERT in SSMS with what EF generates in a later logging lesson.
4. Set Quantity to 0 before save and note whether SQL still runs (it will — add validation in app code).
5. Log _context.ChangeTracker.Entries().Count() before and after Add.

Remember

ORM bridges objects and relational rows. EF Core is .NET's primary ORM. SaveChangesAsync is the commit boundary for tracked changes.

Order line insert without string SQL

ShopNest checkout service adds OrderItem rows through EF instead of concatenating INSERT strings.

Outcome: Parameterized SQL reduces injection risk and survives schema renames at compile time.