153 votes16 comments · [Closed] Entity Framework Core Feature Suggestions · Flag idea as inappropriate… · Admin →James D. Schwarzmeier commented
I agree fully. There are a number of ideas out there very similar to this:
I'm sure there are others too. These all point to a basic need: the ability to leverage the O/R mapping (i.e. SQL generation) capabilities of EF, but bypass the whole change tracking mechanism. It seems to me that there are seven basic things we need to be able to do...there might be more:
- Insert new rows
- Update row for a specific entity
- Update rows matching a WHERE clause (via LINQ, etc.)
- Delete row for a specific entity
- Delete rows matching a WHERE clause (again view LINQ or something)
- Associate entities in a many-to-many relationship
- Remove the association between entities in a many-to-many relationship
Ideally we could essentially build up a series of commands, and then have EF flush all commands out to the DB all at once -- but the key being that the application developer assumes responsibility for knowing what changes need to occur and in what order. Hopefully it would support objects using either foreign key properties OR navigation properties.
This would be especially helpful in some types of disconnected n-tier applications.
192 votes12 comments · [Closed] Entity Framework Core Feature Suggestions · Flag idea as inappropriate… · Admin →