Turn-key Disconnected Entities Solution

[rowanmiller]

Currently we have a bunch of building blocks, such as TrackGraph(...) to help with disconnected entities, but we may want to have something higher level. This would be a more opinionated solution where you follow "our way of doing things" and get something that easily works end-to-end. Obviously we would still have the lower level building blocks for folks that don't want to do it our way.

[saad749]

Any update on this?

[ajcvickers]

Consider discussion/comments from #8744 when implementing this issue.

[jtbrower]

I shake my head often, wondering why I am constantly re-inventing a solution to the same problem when Microsoft should have developed a rock-solid product by now. Especially with such a huge push for Azure. Especially due to the fact that so many applications must operate in a disconnected state these days. Pretty please can we have an off-the-shelf solution?

[sam-wheat]

I think the solution to the Disconnected Entities problem is to completely do away with the concept of "Connected" vs "Disconnected". I also think the concept of Tracking is far more of a hindrance than a help and should be done away with. Just omit it completely. It is the root of too many evils and provides little value in the absolute sense and no value whatsoever relative to the number of problems that it creates.

What pattern that supports todays stateless REST, WCF, and web applications requires or even works with a statefull ORM?
What pattern can demonstrate that a stateful desktop application is any more scalable and flexible when designed to work with a statefull ORM?

The above two questions are valid and deserve to be answered by any proponent of a statefull tracking component for Entity Framework. To the contrary, I will argue that flexible, scalable, testable, n-tier designs strongly favor stateless service layers.

[jzabroski]

@sam-wheat I think you and I are on the same page; I want user stories/scenarios, not big hairy, ambiguous tickets like "turn-key disconnected entities", since I have no idea what that means.

In my opinion, the biggest mistake EF makes is tightly coupling requiredness relationships to Delete. It's one of those solutions only a computer scientist would think up, and it creates gaps/run-time errors when you Delete an "aggregate root" entity without any requiredness relationship defined.

[weitzhandler]

Now that OData made its comeback, it's time to ping this issue again.

As a LoB app dev especially but to any client side dev, this feature is so compelling.
Ideally an OData client side library that wraps around HttpClient and provides entity querying, manipulation, validation and caching, sort of the features of this libraries: Refit, Breeze#, TrackableEntities, and powered by DI and IHttpClientFactory.

Like what RIA Services used to be, R.I.P.

Opened this issue: OData/odata.net#1508

[jangarach]

It's the dawn of 2022 and EF core still can't handle correct deletion when updating untracked entities. This upsets me a lot. As already mentioned, it makes no sense to separate entities into tracked and not tracked. When I call the update command by passing in an entity containing a one-to-many collection and deleting one element in that collection, EF Core does not delete that entity. What for the ORM when it is necessary to do it manually?

[danielrehha]

Please prioritize this issue if possible.