Mastering Entity Framework for Object-Oriented Programming: Beyond Simple DTOs

JetBrains

Introduction & Context [00:00:00]

• Speaker Introduction [00:01:17]
  • Chris Klug, a developer with over 20 years of experience and a Microsoft MVP for 13 years, working at Active Solution in Stockholm.
• Talk Title Clarification [00:03:06]
  • The original title "Stop using Entity Framework as a DTO provider" was updated to "Stop using Entity Framework as just a DTO provider" due to community feedback, acknowledging that EF can be used for DTOs in certain contexts, but shouldn't be limited to it.
• Importance of Context and Trade-offs in Code [00:03:52]
  • All code is written within a specific context and involves trade-offs. It's crucial to accept different opinions and approaches in coding.
• Speaker's Opinionated Architecture [00:04:51]
  • The presented code is heavily influenced by Object-Oriented Programming (OOP) and Domain-Driven Design (DDD), focusing on creating truly object-oriented code.

Understanding DTOs and Their Misuse [00:05:37]

• Definition of Data Transfer Object (DTO) [00:05:43]
  • According to Wikipedia, DTOs are simple objects that carry data between processes and should not contain business logic. Their primary purpose is to shift data in expensive remote calls.
  • Example: A public class Vehicle { public int Id { get; set; } ... } is a typical DTO with no logic or encapsulation.
• Where DTOs should be used [00:06:52]
  • DTOs are suitable for transferring data between different processes, such as between a web app and a database server (though often handled by EF internally).
  • They are acceptable for returning data from an application to a client (e.g., API response).

    

Problems with DTO-centric EF Usage [00:07:32]

• "What's wrong with that?" - Common Developer Perspective [00:07:32]
  • Many developers use simple objects (DTOs) with EF Core for database access because it's often shown in "getting started" guides (e.g., Microsoft Learn's EF Core page).
  • The problem arises when these simple examples are adopted as the entire data access strategy for complex applications.
• Issues with Spreading Business Logic [00:08:48]
  • When entities are just DTOs, business logic often gets spread across "services" or "commands," making it difficult to find and maintain specific business rules for an entity.
• Issues with Data Validation [00:09:32]
  • Without encapsulation in entities, validation logic also gets scattered across services or separate "validator" classes. This creates a risk of forgetting to call validation, leading to invalid data.
• Limitations of Setters for Validation [00:11:01]
  • Using setters for validation often requires throwing exceptions, which many developers don't expect or handle with try-catch blocks, as setters are typically assumed to just work.

Example Domain: DMV System [00:11:36]

• Domain Model Overview [00:12:06]
  • The example domain is a simple DMV system managing vehicles, their owners (persons), and addresses.
  • Relationships:
    • Many-to-many between Vehicle and Owner/Person.
    • One-to-many between Owner/Person and Address.
    • An Address can be a Delivery Address or an Invoice Address.

      

• Database Schema [00:12:32]
  • The database schema includes Vehicles, VehicleOwners (coupling table with From and To dates), People (FirstName, LastName), and Addresses (with Type and IsCurrent columns).

    

Traditional DTO and Service Approach (Critique) [00:13:03]

• Code Example: DTO Models [00:13:11]
  • Models like Address.cs and Person.cs are shown with public get; set; for all properties, including [Required] and [StringLength] annotations directly on them, illustrating the typical DTO approach.
• Code Example: Services with Embedded Logic [00:13:41]
  • PersonService demonstrates validation logic (e.g., checking for null/whitespace in address fields) and business rules (e.g., limiting to three addresses, setting IsCurrent) directly within service methods like SetAddress.

    

  • VehicleService shows similar scattering of business rules (e.g., setting To date for previous owner) in methods like SetCurrentOwner.
• Critique: Spreading logic, violating OOP principles [00:16:09]
  • This approach spreads business logic and validation across services, making it hard to understand an entity's rules and violating OOP principles of encapsulation.

Proposed Solution: Wrapping EF Objects in OOP Entities [00:16:47]

• Concept of OOP-y Wrapper Objects [00:16:52]
  • The idea is to wrap the simple DTOs that Entity Framework maps to (often called "models" or "entities" by EF users) within more object-oriented classes.
  • These wrapper classes would contain the business logic and validation, using the internal DTOs for data storage.

    

• Benefits: Encapsulation, centralized logic, improved readability [00:17:29]
  • This approach centralizes business and validation logic within the domain objects themselves, making the code more readable and maintainable.
  • It ensures that the domain objects are truly object-oriented, with methods that enforce business rules.
• Code Example: Wrapper entities (Person, Vehicle) [00:18:02]
  • Demonstrates a Person entity that takes a PersonDTO (the dumb EF object) in its constructor and exposes methods like SetDeliveryAddress or SetInvoiceAddress, which contain the business logic.

    

  • This effectively hides the EF-specific DTO behind a richer domain object.

Leveraging EF Core for True OOP (Demo) [00:23:00]

• Domain Refinement with Bounded Contexts [00:23:31]
  • To better align with DDD, the domain is split into two bounded contexts: Vehicle Management (handling Vehicle and Owner) and People Management (handling Person and Address). This addresses the conceptual difference between an "owner" in the context of a vehicle and a "person" with an address.

    

• Database Mapping Strategies [00:24:12]
  • Discusses Table Splitting and Multiple DbContexts as ways to map different entities to the same database table.
  • Table Splitting allows one DbContext to map multiple entity types to the same table, useful for representing different domain concepts that share underlying storage.
• Added Benefit: Might not need Lazy Loading [00:25:54]
  • By using well-defined aggregate roots (from DDD), entities are designed to be smaller and load all necessary data eagerly, potentially eliminating the need for lazy loading, which can have performance downsides.
• Demo: Mapping the Domain OOP-style [00:26:38]
  • Setting up Entities (Vehicle, Vin, Owner) [00:29:06]
    • Vehicle class designed with a private list of Owners and a Vin (Vehicle Identification Number) property.
    • Using Value Objects (Vin, Name) [00:29:48, 00:31:09]
      • Vin is implemented as a record (value object) that encapsulates VIN validation logic.
      • Owner has an ID and Name (also a value object for First/LastName), and From/To dates for ownership periods.
  • Manual Migrations [00:31:39]
    • Emphasizes creating manual C# migrations for better control, rather than relying solely on auto-generated ones.
    • Demonstrates creating Vehicles, People, VehicleOwners, and Addresses tables with appropriate columns, primary keys, foreign keys, and indexes.
  • Mapping Entities to Database [00:37:02]
    • All EF mapping is done explicitly in OnModelCreating to avoid data annotations and adhere to clean domain objects.
    • Vehicle Mapping:
      • Uses a Shadow property for ID (HasKey("ID")) so the entity doesn't need a public ID property, as Vin is the natural identifier.
      • HasConversion is used for Vin to tell EF how to convert the Vin value object to a string for the database and vice-versa.
      • AutoInclude() is used for Owners to ensure they are always loaded with the Vehicle, assuming the collection isn't excessively large.
    • Owner Mapping:
      • Maps Owner to the VehicleOwners table, using Person as a private field mapped to the People table through HasOne().WithOne().HasForeignKey().
      • A Composite key (VehicleId, PersonId) is defined.
    • Person Mapping:
      • HasComplexProperty is used for the Name value object, mapping its FirstName and LastName properties to corresponding database columns.
      • Uses IEntityTypeConfiguration<T> to separate mapping logic into dedicated classes (PersonTypeConfiguration, AddressTypeConfiguration) for better organization.
    • Address Mapping:
      • Uses a Discriminator to map DeliveryAddress and InvoiceAddress (inherited from an abstract Address base class) to the same Addresses table based on a Type shadow property. This allows EF to understand the inheritance hierarchy in the database.
  • Implementing Services [00:43:46]
    • Shows how services interact with these rich domain objects.
    • GetVehicleByVin uses a custom extension method (VehicleWithVin) on DbContext to query for the Vehicle entity using the Vin value object.
    • GetVehicleById demonstrates querying by a shadow property (EF.Property<int>(x, "ID")) not explicitly present on the entity.
    • GetCurrentOwnerWithVin illustrates using LINQ projections to select only specific data needed for a DTO, avoiding loading entire objects for read operations.
    • AddVehicle and SetCurrentOwner methods are simplified as the business logic is now encapsulated within the Vehicle entity, making the service code clean and focused on orchestration.
  • Refining Person Entity with ID Interface for controlled access [01:06:51]
    • The Person entity implements an IHasId<int> interface, allowing controlled access to its ID property without making it publicly mutable or visible by default. This maintains encapsulation while enabling ID-based operations when explicitly cast.
  • DTO Extension Methods [00:47:36]
    • Simple extension methods (ToModel) are created to convert domain entities into DTOs for returning data from services, avoiding external mappers like AutoMapper for basic cases.

      

  • Running Tests [01:01:49]
    • The speaker demonstrates running unit tests that successfully validate the OOP-style entity mappings and service interactions.
  • IDesignTimeDbContextFactory for EF Tools [01:13:22]
    • The IDesignTimeDbContextFactory is used to provide a context for EF Core tools (like migrations bundle) without needing a full application startup.

      

Key Takeaways and Best Practices [01:08:26]

• Map to objects that look like you want them to look (OOP First) [01:08:32]
  • Design your domain entities with full OOP principles (encapsulation, rich behavior), then use EF's mapping capabilities to persist them. This is especially important for commands (write operations). For queries (read operations), mapping to simpler DTOs is acceptable.
• Use aggregates and AutoInclude() instead of lazy-loading [01:09:00]
  • Design DDD aggregates to be small enough that AutoInclude() can load all necessary data without performance issues, reducing the need for potentially problematic lazy loading.
• Use read-specific queries (projections or raw SQL) if performance is a problem [01:09:13]
  • For highly optimized read scenarios, use LINQ projections to select only the necessary columns into a DTO or even write raw SQL queries mapped to non-mapped entities if EF's LINQ translation is insufficient (EF Core 8+ supports this).
• Consider split queries for complex joins [01:09:48]
  • If a query with many Include() statements generates a Cartesian product and pulls too much redundant data, use AsSplitQuery() to tell EF to send multiple, simpler queries to the database.
• Use directional navigation instead of bi-directional [01:10:06]
  • Avoid bi-directional navigation properties in your domain models to prevent accidental loading of entire graph databases into memory, which can happen with deep traversing.

    

• Do not map ID and entity when mapping relationships; choose one! [01:10:40]
  • When defining relationships, either map the foreign key ID or the navigation property (entity), but not both, to prevent confusing behavior where setting one implicitly affects the other.
• Do not migrate your database as part of your application setup [01:11:22]
  • Migrating the database on application startup (Program.cs) is problematic in load-balanced environments, as multiple instances trying to migrate simultaneously can lead to failures and application downtime.
  • Instead, generate an EF migrations bundle executable (dotnet ef migrations bundle -o migration.exe) and run this tool as a separate step in your deployment pipeline.