Managing LINQ to SQL .dbml model complexity

Question

This question is addressed to a degree in this question on LINQ to SQL .dbml best practices, but I am not sure how to add to a question.

One of our applications uses LINQ to SQL and we have currently have one .dbml file for the entire database which is becoming difficult to manage. We are looking at refactoring it a bit into separate files that are more module/functionality specific, but one problem is that many of the high level classes would have to be duplicated in several .dbml files as the associations can't be used across .dbml files (as far as I know), with the additional partial class code as well.

Has anyone grappled with this problem and what recommendations would you make?

Answer 1

Take advantage of the namespace settings. You can get to it in properties from clicking in the white space of the ORM.

This allows me to have a Users table and a User class for one set of business rules and a second (but the same data store) Users table and a User class for another set of business rules.

Or, break up the library, which should also have the affect of changing the namespacing depending on your company's naming conventions. I've never worked on an enterprise app where I needed access to every single table.

Answer 2

Past a certain size it probably becomes easier to work with the xml instead of the dbml designer.

Answer 3

I have written a tool too! Mine is for scripting changes to dbml files using c# so you can rerun them and not lose changes. See my blog http://www.adverseconditionals.com 4 more details