I disagree with John’s answer. The DataContext (or Linq to Entities ObjectContext) is more of a “unit of work” than a connection. It manages change tracking, etc. See this blog post for a description:
Lifetime of a LINQ to SQL DataContext
The four main points of this blog post are that DataContext:
- Is ideally suited
for a “unit of work” approach - Is also designed for
“stateless” server operation - Is not designed for
Long-lived usage -
Should be used very carefully after any SumbitChanges() operation.
Considering that, I don’t think using more than one DataContext would do any harm- in fact, creating different DataContexts for different types of work would help make your LinqToSql impelmentation more usuable and organized. The only downside is you wouldn’t be able to use sqlmetal to auto-generate your dmbl.