I'm not sure I understand what all fall under the disconnected context scenarios in EF (See this and this). This link says use Web API or WCF services to avoid the complexities of disconnected tier EF solutions.

Here's my understanding. If I create a new DbContext, get some entities, pass it to another process/machine (anything outside the scope of the current context), and there I make some changes to these entities and try to save them, then this is a disconnected scenario. EF will not know whether it is an Add or Update or what fields have changed, unless I explicitly tell it.

Suppose I have an MVC app, with a UserController. The UserController takes in a IUsserService through dependency injection. UserService, the concrete implementation of IUserService takes in a UnitOfWork. My DbContext is instantiated for the UnitOfWork, and SaveChanges() is called only on Commit() of the UnitOfWork. I also set the lifetime of the DbContext in Unity as PerRequestLifetime -> which means one instance is created for each HttpRequest. My UserService works with different entities required to do its job. I believe this is not a disconnected scenario, since my context is the same throughout?

If my MVC controller were in one machine (web), and the UserService in another machine(app - http endpoints exposed using webapi), does anything change? In this case, I need the DbContext only starting with ApiController, and everything will stay within the app layer. So I still avoid disconnected contexts. Am I right?

If I'm not clear, I can put some code, but nothing different in there.

1 Answer 1


The words "disconnected context" refer to the fact that most modern web applications only connect to the database long enough to retrieve and store data for the lifetime of a single web page. While they might maintain a session, they do not typically maintain a persistent database connection like a client/server application does.

Basically what they are saying is that there are now better facilities for handling disconnected data scenarios, such as Web API and WCF Services. These services handle all of the complexity behind the scenes of storing and retrieving data (with your programming help, of course), while maintaining a front-facing API that is REST compliant.

  • So, I typically wouldn't have to do something as complex as this if I'm using WebAPI (and i implement all EF logic encapsulated in a repository/UoW pattern)? genericunitofworkandrepositories.codeplex.com/SourceControl/…
    – Narayana
    Commented Jan 28, 2014 at 17:09
  • That is exactly what you would do. The repository is the abstraction you need to provide a container for your Unit of Work pattern. Commented Jan 28, 2014 at 17:13

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.