I've been reading lately about disconnected DataContexts but there's a few things I don't understand. There seems to be a scenario where you'd want to use a disconnected DataContext and then a scenario where you have to use one.
Why might you want to use a disconnected DataContext? In a single machine scenario I don't think it violates separation of concerns by accessing the DataContext from the Controller [in mvc apps of course] (certainly you wouldn't pass the DataContext to the view - and you don't need to anyway since you're passing model objects), so I'm not sure when you'd want to use a disconnected DataContext.
I think I understand why you'd have to deal with disconnected DataContexts, which would be in scenarios where you need to pass objects to other machines/physical tiers while maintaining change tracking. And I assume that you can't pass the DataContext across these boundaries possibly because the database connection can't be maintained statefully by machines other than the originating one? Is this correct or are their other reasons you can't pass the DataContext in this way?
Finally, what are the other scenarios in which you'd have to use disconnected DataContexts?
why not pass a data context around? You're not voilating separation of concerns by having the data context in the controller anyway. I guess you can't pass the data context across machine boundaries b/c by definition not all machines can talk to the db?