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.