Question

I’ve been working on a project where I have been using LinqToSQL that involved a lot of tables. All of these where mapped in one .dbml file (i.e. only one DataContext). I did this on the pretense that (currently) you cant join across multiple data contexts. For example…

DB1DataContext db1 = new DB1DataContext();
DB2DataContext db2 = new DB2DataContext();

var query =
    from x in db1.SomeTable
    join y in db2.AnotherTable on x.Id equals y.Id
    select new
    {
        x.Column,
        y.Column
    };

Someone argued that this isn’t so, and I should break the .dbml file down into seperate smaller (i.e more managable) data contexts. I’ve now just set up an example, run a similar query to the one above and got the following error…

base {System.SystemException} = {“The
query contains references to items
defined on a different data context.”}

I am curious, am I missing something? What are the common practices where there are a lot of tables that require mapping? How can you break down a .dbml file?

Answer 1

This was asked several times here and there is no definite answer. Check this questions:

• LINQ to SQL: Multiple / Single .dbml per project?
• Are Multiple DataContext classes ever appropriate?
• Linq to SQL and large DB model
• Managing LINQ to SQL .dbml model complexity
• Best Practices for Managing Linq to SQL Dbml Files?

Some answers refer to this blog post: Lifetime of a LINQ to SQL DataContext