DbContext is just a wrapper around ObjectContext. DbContext is just a set of APIs that are easier to use than the APIs exposed by ObjectContext. Anyway, here you’ll find a very simple Visual Studio template that uses the Repository Pattern and the Entity Framework.
This happens because of NSubstitute syntax specific. For example in: ((IQueryable<Blog>) mockSet).Provider.Returns(data.Provider); NSubstitute calls the Provider’s getter, then it specifies the return value. This getter call isn’t intercepted by the substitute and you get an exception. It happens because of explicit implementation of IQueryable.Provider property in DbQuery class. You can explicitly create substitutes for multiple … Read more
The point is that Find() starts by searching in the local cache of the context and then, if no match, sends a query to the DB. Call to Where() always sends a query to the DB. With EF 4, I used to think that SQL generated by Find() was too complex and, in some cases, … Read more
Setting AutoDetectChangesEnabled to false doesn’t disable change tracking. (That’s what the AsNoTracking() extension method would do.) It just disables the automatic call of DetectChanges that would otherwise occur in many DbContext API methods. But DetectChanges isn’t the only method that participates in change tracking. However, if you don’t call it manually at the right places … Read more
I found the answer. Of course, it is possible to convert DbSet in Entity framework to ObjectQuery using the below lines of code. ObjectContext objectContext = ((IObjectContextAdapter)db).ObjectContext; ObjectSet<Request> objectSet = objectContext.CreateObjectSet<Request>(“Requests”); where, db – Context class inherting from DbContext. Requests – DbSet<Request> defined in Context class. objectSet – Can now be passed as ObjectQuery.
When you use dbContext.SomeEntitySet.Add(entityInstance); the status for this and all its related entities/collections is set to added, while dbContext.Entry(entityInstance).State = EntityState.Added; adds also all the related entities/collections to the context but leaves them as unmodified. So if the entity that you are trying to create has a related entity (and it’s value its not null), … Read more
Using any context.XyzAsync() method is only useful if you either await the called method or return control to a calling thread that’s doesn’t have context in its scope. A DbContext instance isn’t thread-safe: you should never ever use it in parallel threads. Which means, just for sure, never use it in multiple threads anyway, even … Read more
I just found that the Enumerable result should be evaluated because the Refresh method gets it as object and doesn’t evaluate it. var context = ((IObjectContextAdapter)myDbContext).ObjectContext; var refreshableObjects = (from entry in context.ObjectStateManager.GetObjectStateEntries( EntityState.Added | EntityState.Deleted | EntityState.Modified | EntityState.Unchanged) where entry.EntityKey != null select entry.Entity).ToList(); context.Refresh(RefreshMode.StoreWins, refreshableObjects); And I prefer the following: var refreshableObjects … Read more
With Entity Framework Core (tested with Version 2.1) you can get the current context using // DbSet<MyModel> myDbSet var context = myDbSet.GetService<ICurrentDbContext>().Context; How to get a DbContext from a DbSet in EntityFramework Core 2.0
Yes. SaveChanges uses transaction internally. Use TransactionScope to wrap multiple calls to SaveChanges Example: using(var scope = new TransactionScope(TransactionScopeOption.Required, new TransactionOptions { IsolationLevel = IsolationLevel.ReadCommitted })) { // Do something context.SaveChanges(); // Do something else context.SaveChanges(); scope.Complete(); }