ASP.Net MVC: Best Practices for dbml files

Question

This may just be a yes or no type of question but here goes anyway...

From all (well most) of the examples that I've seen for using mvc, it appears that method for creating the dbml file is just drop the entire schema of the database into it and let it autogenerate all of the linq to sql goodness. It appears that you just need one of these (as you can't have duplicate tables in separate dbml files in the same project) but for some reason it would seem like there's a better way to do this...especially when dealing with a large project that has a fair number of tables.

So is this the proper way to go about creating a dbml file to use in a mvc project, just drop the entire table structure into and go to town? If not, how do you do it?

Answer 1

If the schema was large, I think i would be relying fully on a SQLMetal script to generate my *.dbml and backing classes. This way you can just regenerate your entire data model whenever your database gets updated. Otherwise, if a table, view, etc, gets updated in the database you don't have to delete and then re drag-and-drop that table into your visual *.dbml file.

Actually, I am not expert with SQLMetal, but I think you can even use it it to generate everything you need for Linq-toSql and not even require/generate a *.dbml file.