Non sono sicuro di capire che cosa rientrano tutti negli scenari contestuali disconnessi in EF (vedi questo e questo ). Questo link dice che utilizzare i servizi API Web o WCF per evitare la complessità delle soluzioni EF di livello disconnesse.
Ecco la mia comprensione. Se creo un nuovo DbContext, ottengo alcune entità, passalo a un altro processo / macchina (qualsiasi cosa non rientra nell'ambito del contesto corrente), e lì apporto alcune modifiche a queste entità e provo a salvarle, quindi questo è uno scenario disconnesso . EF non saprà se si tratta di aggiungere o aggiornare o quali campi sono stati modificati, a meno che non lo dica esplicitamente.
Supponiamo di avere un'app MVC, con un UserController. L'UserController accetta un IUsserService tramite l'iniezione delle dipendenze. UserService, l'implementazione concreta di IUserService richiede un UnitOfWork. Il mio DbContext è istanziato per UnitOfWork e SaveChanges () è chiamato solo su Commit () di UnitOfWork. Ho anche impostato la durata di DbContext in Unity come PerRequestLifetime - > il che significa che viene creata un'istanza per ogni HttpRequest. Il mio UserService funziona con diverse entità necessarie per svolgere il proprio lavoro. Credo che questo non sia uno scenario disconnesso, poiché il mio contesto è lo stesso in ?
Se il mio controller MVC era in una macchina (web) e UserService in un'altra macchina (app - endpoint http esposti con webapi), qualcosa cambia? In questo caso, ho bisogno che DbContext inizi solo con ApiController e tutto rimarrà all'interno del livello dell'app. Quindi evito ancora i contesti disconnessi. Ho ragione?
Se non sono chiaro, posso inserire del codice, ma non c'è niente di diverso lì dentro.