Entity Framework: Domain Modelling Approaches

Overview

The Entity Framework provides three separate approaches to work with data models and each one has its own pros and cons.

Possible Approaches

Model First 

• The database model (Entities, relationships and inheritance hierarchies) is created first using the ORM designer in Visual Studio. Once the model is ready the database is created from it.
  
• The Model First workflow begins with an empty slate. You use the visual EDM Designer to design an EDM then generate a database schema from that model.

Code First

• The classes (known as POCO classes) are created first and then generates the database from the classes directly.
  
• If the database is ready, the Entity Framework tools can generate the classes and properties that correspond to existing tables and columns.
  
• The Code First workflow begins with classes that describe a conceptual model. There's no visual model used with Code First.

Database First

• The model is created from an existing database (like SQL Server, Oracle and so on).
  
• Workflow begins with a legacy database and leverages a wizard to reverse-engineer that database into a conceptual model.

Model First vs Code First vs Database First

Model First	Code First	Database First
Define the model and go with the workflow to generate a database script and T4 template to generate POCO entities	Create POCO classes and then create the database from the POCO classes The code defines the database mappings and EF handles the creation of the database with its relations	The EDM wizard creates entities, relationships and inheritance hierarchies. After modification of the mapping, the POCO class entities are created.
For additional features in POCO entities, either T4 modify template or use partial classes		For additional features in POCO entities you must either T4 modify template or use partial classes.
Code is automatically generated	Full control over the code, no auto-generated code	The code is automatically generated.
This approach is adopted by the architect and solution lead developers	This approach is adopted by developers who follow the path of Domain-Driven Design (DDD) principles	Recommended if the DB is designed by DBAs, developed separately or the DB already exists
Manual changes to the database will be most probably lost because the model defines the database	Manual changes to the database will be most probably lost because your code defines the database	Manual changes to the database are possible because the database defines the domain model. The model can be updated from the modified database.

Choose Best Suitable Approach

References

Entityframeworktutorial

DotnetTricks