Linq to SQL and large DB model

Question

First, I am Linq to Sql newbie, so please be gentle :).

I have existing ASP.Net application developed over last 3.5 years. It has pretty big data model underneath, around 350 tables. I am trying to do some new things with Linq to SQL.

First impression is that linq designer and SqlMetal are built for databases not bigger than NorthWind example. Here are some problems I have:

1. I have table Products that is needed in lots of places (inventory, invoicing, production, ...). If I put table Products in each dbml file, linq designer is going to create Product class in each of them. I don't want that. I want to only one Product class.
2. I have DataContext about shipping. It needs around 40 tables. This makes dbml file very hard to manage. Is there a way to create smaller dbml files and then include them (as reference) into some "major" dbml?

For now, I really like Linq, but I think it is still seriously lacking design tool for anything bigger than 10 tables.

My solution now is building smaller models with Linq designer and then manually merging them (adding properties and references), so lots of code will be generated, but there will also be lots of manual work.

Did I miss something big or is this current state of affair with Linq to Sql?

Answer 1

If I were you I would be using Entity Framework as this is the MS recommended ORM going forward Microsoft kills Linq to SQL

Answer 2

Have you come across this article on MSDN?

http://msdn.microsoft.com/en-us/library/bb387007.aspx

It seems there is a command line tool to generate the Object Model without using the visual designer in VS.net.

Answer 3

Why do you want multiple dbml files? Just stick them all in one. Thats how it's meant to work.

Answer 4

Hi Zendar - well, my solution was to use SQLMetal's /code option to create plain classes in a .cs file instead of a DBML file, and use partial classes in a separate file to extend the generated ORM classes.

I know that doesn't solve your issue of splitting parts of your database into different ORM assemblies - I just found that without the headache of the DBML / Designer, managing a large number of classes in a .cs file wasn't too bad.