How many linq-to-SQL datacontexts per solution? I get the "menber is defined more than once" error

I have a relational database with about 15 tables that will be used in 4 different aspx pages (for now). Each aspx page uses some of the tables, but never all tables at once: for instance, one page might use 4 tables while another page might use 6 tables. I started doing a dbml file for the first aspx file with just the 4 tables needed. When I got to the second aspx file, I did another dbml file with just the 6 tables that were needed for this aspx file. 2 of the tables are in both datacontext dbml files and I get a "member is defined more than once" error.

After reading some online posts, my question about dbml files is this: when using linq-to-SQL, for an application, can w开发者_运维知识库e create multiple dbml files with the same tables or do we have to do just one dbml file for the whole application because a table can only be in one dbml file. If the latter is the case, do we need to simply include every database table in the dbml file and then always use the same datacontext throughout the project.

Thanks.

The dbml file shouldn't be the problem, but I guess you are using the designer, which automatically generates code - if you use two designers in the same namespace, the class names will collide. You've got three options then:

1. different namespaces
2. do the code generation yourself
3. use one datacontext with all tables.

Personally, I always go with 3., because linq-to-sql does support lazy loading, ie. there will be no resources spent if you don't query for any data.

dbml files are (after design time) irrelevant. What matters is the Designer.cs files they generate.

It sounds like you might be able to use 1 dbml file and then hand-code a CustomDataContext class to meet each page's needs.

The 'member is defined more than once' error occurs because you have two same-named classes in the one namespace.

Say one of your tables is called Product. When you drag that table onto the dbml (or rather when you save the dbml), the designer generates a lot of code in the default namespace, including a class called Product which contains properties for all the database columns. That's what you want but if you then go and create another dbml file in the same namespace, and drag Product onto the second dbml file, you'll end up with two Product classes in the same namespace - hence 'defined more than once'.

The solution is to change the Entity Namespace property on the dbml designer. Open the dbml, and without selecting any tables or relationships open the properties window. Under the Code Generation group there is a property called Entity Namespace. If you change that one to something else, you'll resolve the problem.

e.g. you might change it from MyProject to MyProject.Customers, or MyProject.Inventory.

The other option, as pointed out by Femaref, is to use a single datacontext for all pages. From what I read this is probably the more common pattern. I've only used multiple contexts when I have a large number of tables because the single dbml approach is unmanageable. But whatever works for you!