274 votes11 comments · Entity Framework Feature Suggestions » runtime · Flag idea as inappropriate… · Admin →
Reverting status from “under review” to “no status” since we aren’t currently working on this. We will still consider it for future releases.
Do people realise that you can make the default contructor protected?
Same goes for properties - you can make the setter protected.
670 votes14 comments · Entity Framework Feature Suggestions » runtime · Flag idea as inappropriate… · Admin →
This feature is currently planned to be included in EF7.
I have already commented on this once, so apologies for the spam - but every time I come back to this it seems worse.
I know there is plenty of code around where people are accessing their DbContext directly in the service or UI layers of their applications where this wouldn't be so much of an issue.
But.... if you have properly wrapped Entity Framework up in your data access layer this gets really annoying. It means you end up having to create a DAO for every entity that you might possibly need to delete. Normally I would only have DAOs for the main entities in my application, and manage their children via the collections hanging off them.
Please fix this.Jordan M supported this idea ·
This is a must have feature. I cannot believe that Entity Framework hasn't got this, This gives NHibernate a simple but significant advantage.
This is an ORM - the O stands for "Object" and one of the *main* benefits of using an ORM is that as much as possible it should allow you to do object oriented programming. Automatically syncing trees of objects to the database is a massive part of that.
If a collection of an entities makes up part of its parent, if one of those objects is removed from its parents collection then it should be deleted from the database. You shouldn't have to then go and delete it again using a call to your data access layer.
I wouldn't have static methods on the entities themselves, this goes against the way the framework is currently designed.
I would add methods to the DbContext or DbSet<TEntity>, something similar to Keith Barrows suggestion.