I just noticed that EF (using version 5 here) doesn’t provide DeleteAsync()/AddAsync(). I also noticed that projects like this one:
https://github.com/zzzprojects/EntityFramework-Plus
do provide DeleteAsync() as an afterthought. Why doesn’t EF provide DeleteAsync() out of the box? Just curious.
Addendum: As pointed out by the maintainer of EF-Plus the ‘DeleteAsync’ flavor I mentioned is somewhat different than ‘Delete’/’DeleteAsync’ of EF in the sense that the former operates on a query targeting elements that will be matched on the db/db-server, while EF’s Delete operates on elements that have already been retrieved before ‘Delete()’ is invoked. Despite this difference in the signature of these methods the original concern raised by my question maintains its merit.
Advertisement
Answer
After watching the very enlightening material provided by MattJohnson and after probing into the implementation of Delete using reflection I surmised that the reason behind DeleteAsync() not being provided, is that delete causes the database to be changed within a single unit-of-work-instance-lifecycle.
IF someone provided a ‘DeleteAsync()’ operation through Task.Run() (aka without a true async implementation) this would effectively be inducing illusions through anti-patterns in the sense that developers would use this sort of API thinking they enjoy the benefits of ‘true-async’ but in reality they would not – they would only just suffer from unnecessary overhead ala ‘await Task.Run(() => context.Foo.Delete(x))’ without enjoying any benefits whatsoever.
TL;DR: The bottom-line explanation on why the folks of EF dont offer ‘DeleteAsync()’/’AddAsync()’ is that ‘async methods shouldn’t lie’ (as MattJohnson pointed out) and ‘DeleteAsync()’/’AddAsync()’ would be bound to lie given the current implementations of EF at the time of this writing.