7

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?

zendar
  • 13,384
  • 14
  • 59
  • 75
  • I don't have an answer but am interested in knowing this as well since I've noticed the same thing. The methods you are using are what I thought I would do as well if I had a lot of tables. – dtc Nov 08 '08 at 23:16
  • I don't understand why SqlMetal isn't the answer to your question? It worked fine for me with large multi-table databases. I just hooked up a batch script to the "External Tools" menu in Visual Studio so I could rebuild the ORM with one click. – James McCormack Sep 09 '10 at 08:55
  • @James McCormack: could you please add answer and describe how do you organize classes. What I would like is to have assembly Inventory and inside some 20-30 classes that correspond to same number of tables. Then assembly Sales, then Finance. I did not find easy way to automate this, so I resorted to this: create dbml for small number of tables then manually edit code. Do you know if SqlMetal for .Net4 is improved? – zendar Sep 09 '10 at 09:38

4 Answers4

3

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.

James McCormack
  • 9,217
  • 3
  • 47
  • 57
1

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

GeekyMonkey
  • 12,478
  • 6
  • 33
  • 39
  • I think one of the problems is that when you start adding a lot of database the designer starts getting impossible to use. – dtc Nov 09 '08 at 00:19
  • Did you try to put 350 tables in one dbml? – zendar Nov 09 '08 at 12:20
  • All in one is neat for small models. However, the point of having a model diagram is to get an overview. Dividing the model up into subject areas makes it easy to overview, a single 300 table model is impossible to overview. – KristoferA Nov 17 '08 at 03:21
0

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.

dtc
  • 10,136
  • 16
  • 78
  • 104
  • That would be SqlMetal which the OP mentioned. – hangy Nov 08 '08 at 23:42
  • Ok, I wasn't sure because the article says about the SQL Metal code generator: "Modeling large databases is best done by using this tool." – dtc Nov 09 '08 at 00:18
-5

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

user17060
  • 412
  • 5
  • 7
  • I don't think this answers the question and I think EF has the same drawbacks when we are talking about trying to model 350 tables in a single EF file or smaller groups of files. – dtc Nov 08 '08 at 23:17
  • 1
    The EF designer is even worse at handling large models. Both designers need a "paged" approach allowing models to be chunked up into small, digestable views. Or split/merge feature allowing many small designer models to be merged into a single object model. – KristoferA Nov 17 '08 at 03:19