I am working on a web application using ASP.NET 3.5. The application has hundreds of tables. I was told in a seminar that I should use one .DBML file for the entire application instead of using multiple .DBML files (there was also a post in stackoverflow that said the same thing). Given that I have so many tables does using one .DBML file make sense or am I better off creating multiple .DBML files that are logically grouped?
For instance, I was thinking of creating the following .DBML files:
- Customer
- Vendor
- Employee
- Sales Order
One of the concerns that I have about using multiple .DBML files is how I would handle updates across .DBML files. For instance, if I had to update a field on the customer table when a new sales order was entered. How would I handle that? I certainly don’t want to include the customer table in both the Customer and the Sales Order .DBML files. Could I wrap the operations in a TransactionScope?
I don’t know if the following has any impact on the answer, but my plan is to use the repository pattern and POCO classes so that references to the table definitions in the .DBML file will be local to my data access layer.
Thanks
I would have to advise you to use ONE dbml file for all your tables.
If you are trying to join two tables from different data contexts, it makes your code more convoluted. It can be done by simulating cross context joins, but why put yourself in that situation. Keep it simple stupid.
Also, if you do decide to go with 2 or more dbml files and you mistakenly add the same table to multiple data contexts, then you will get a “This member is defined more than once” error.