Linq to Sql Data class in dbml

Question

I am abit curious about dbml.... Should I create one dbml file for one database or separated into different parts e.g. User dbml (only tables relate to users) etc? When I do this I will have abit of problems. Assume the User dbml has a User table and if the Order dbml has a User table as well, this won't be allowed if the entity namespace are the same. If I have set a different entity namespace for each of the dbml, it works but this will gives me a different entity of User table. When a single data returns to Business Logic layer, there is a difficulty of knowing which entity namespace of the user table to be used.

If I built one dbml file instead of having separate dbml, will single dbml appear slower than the separated dbml version when fetching the data from the database.

Answer 1

Linq to SQL is designed to be operated with a single Data Context object.

Lifetime of a LINQ to SQL DataContext
http://blogs.msdn.com/dinesh.kulkarni/archive/2008/04/27/lifetime-of-a-linq-to-sql-datacontext.aspx

The NerdDinner tutorial has a pretty good example of typical Linq to SQL usage, using a repository pattern. In all cases, the repository objects use a single Data Context object to perform the work:

http://nerddinnerbook.s3.amazonaws.com/Part3.htm

What you are trying to do sounds like it might be more suitable for the Entity Framework. Be advised, however, that the Entity Framework has some issues in its present release, particularly with regards to lazy loading.