Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

Managing LINQ to SQL .dbml model complexity

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?

like image 949
Scott Nichols Avatar asked Sep 03 '08 17:09

Scott Nichols


3 Answers

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.

like image 161
Jarrett Meyer Avatar answered Oct 09 '22 04:10

Jarrett Meyer


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

like image 37
liammclennan Avatar answered Oct 09 '22 02:10

liammclennan


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

like image 36
mcintyre321 Avatar answered Oct 09 '22 03:10

mcintyre321