Entity Framework

Posted by Ian King on May 05, 2026 Code

Entity Framework Without a Data Model

TL;DR
Use Sparx Enterprise Architect to define the schema, generate DDL, scaffold with Entity Framework, and use migrations for deployment. The model is the source of truth—not your DbContext.


Entity Framework gives you two familiar paths:

  • Database First → scaffold entities from an existing database

  • Code First → generate the database from C# classes

Both are useful.

Neither is data modelling.


The gap

In both approaches, the schema is an afterthought:

  • Database First → reflects whatever already exists (good or bad)

  • Code First → pushes developers to think in classes, not data

What’s missing is intentional structure:

  • Entities

  • Attributes

  • Relationships

  • Normalisation (3NF)

Without that, EF becomes a schema generator, not a design tool.


The alternative (model-first)

Flip it.

  1. Model the database in Sparx Enterprise Architect

    • Define entities, keys, relationships

    • Normalise properly (3NF as a baseline)

  2. Generate the DDL from the model

  3. Apply it to the database

  4. Use Database First in Entity Framework to scaffold/update entities

  5. Use Code First migrations to deploy changes across environments


Why this works

  • The model drives the schema

  • The schema drives EF

  • EF becomes a consumer, not the source of truth

This enforces:

  • Proper keys and relationships

  • Consistent structure across environments

  • A single place to reason about change


On normalisation

EF doesn’t care about 3NF.

You should.

A properly modelled schema:

  • Eliminates duplication

  • Prevents anomalies

  • Makes relationships explicit

If you skip this step, EF will happily generate a database that works—but doesn’t scale cleanly.


My take

Code First feels productive because it’s fast.

But it bypasses the hardest (and most important) part: data design.

Database First reflects reality—but doesn’t improve it.

Model-first forces you to:

  • Think in data, not objects

  • Design relationships intentionally

  • Treat the database as a first-class system


Bottom line:
If your EF model defines your database, you’re designing backwards.
Design the data model first—EF should follow, not lead.