If the goal is to be able to swap out backend DB providers (EF, OleDB, ODBC, etc) then I'm wondering where the different DB CRUD changes? Currently I have an interface (IGenericContext) that has Add/Update/Delete/Select functions. I then make an ADOContext which implements this and inside these functions is where I do the SQL statements. For Add/Update/Delete this is fine, but select is interesting as I just take a string which is the sql. So in my repository where I have functions like, GetAllTasks() I just call that context.Select function with the sql statement.
However, if I then create an EFContext you wouldn't be able to call this Select function with the string sql. You'd do something that involved Linq which means my Repository needs the code change if I switch the context. Now that's better than the business layer needing a change, but it still seems like it would be nice to not have to change the repository as it's really the context that should handle those things and need to be changed and for Update/Add/Delete it does, but selecting seems more unique by context type.
How would you handle something like that? Imagine I created a text file context for that matter. It seems like it's fairly easy to hide the details of Add/Update/Delete but it's harder to hide the details of select from context from within the repository.