search

dotnet / EntityFramework.Docs

Documentation for Entity Framework Core and Entity Framework 6
https://docs.microsoft.com/ef/
Creative Commons Attribution 4.0 International
1.63k stars 1.96k forks source link

Update Cascade Delete documentation's delete scenario table to explain interaction with lazy loading and proxies #844

Open jzabroski opened 6 years ago

jzabroski commented 6 years ago

As discussed in https://github.com/aspnet/EntityFramework.Docs/pull/810 It isn't obvious how Cascade Delete interacts with lazy loading and proxies.

ajcvickers commented 6 years ago

@jzabroski Can you provide more details on what you mean by, "how Cascade Delete interacts with lazy loading and proxies?"

jzabroski commented 6 years ago

If you don't eager load the sub-entities, and never trigger a lazy load of the sub-entities, then the EF Cascade Delete behavior is sub-optimal, in that it will only Delete the "Aggregate Root". The workaround is to set Cascade Delete at the database level, but this is typically a Domain-Driven Design anti-pattern.

My boss and I both found the documentation less than clear, and dislike that there is no alternative. However, absent improving Cascade Delete of entities not loaded into memory, better documenting this "shortcoming" should help others.

I believe "improving Cascade Delete of entities not loaded into memory" probably falls under https://github.com/aspnet/EntityFrameworkCore/issues/11240#issuecomment-372488780

This is as much a performance issue as it is about having a "conversational context" with our domain model. The meaning of delete should belong to our ModelBuilder logic, not in the application layer. The application layer should just have a conversation with the repository about deleting stuff, and the repository should delegate to the ORM to do the delete, and the needful delete should come from the ModelBuilder.

Tangent: The phrase "conversational context" comes from my college days >10 years ago, reading about a novel web application framework called Seam. In particular, Seam In Action by Dan Allen, especially Part 3: Seam's State Management, Chapter 7: The conversation: Seam's unit of work. Effectively, while ORMs helped automate object materialization and persistence, there was still a lot of "bookkeeping code" in our applications that inhibited us as engineers from "having a conversation with our domain model" and only focusing on the domain model when coding. The spirit of Seam's goals was something I deeply internalized as an architect, albeit I did not agree with how they did it (business scope vs. conversation scope).