Linq to SQL - a design issue

Question

HI, I currently have one big datacontex with 35 tables (I dragged all my DB tables into the constructor). I have to admit that this is very convenient, because I have an ORM for my full DB and the query with linq is simple and simple.

My questions: 1. Do you think that a bad design has one datacontext with 35 tables or should I split it into logical units? 2. Are there any penalties for using such a large data file?

Thanks, Pini.

Answer 1

• Divide into logical devices
• There are no real penalties for performance, as it will not be easy to have a review.

Answer 2

There is a performance penalty because it restores the metamodel for all mappings every time you create a new context, but if you control it and not cause problems, then I will not worry about it.

I use only a DataContext for very small projects that need only a few tables that would be more similar to what would be easier, and in the long run, that would be easier in a more traditional and mature ORM like nHibernate, in my sight.

Answer 3

I can understand your pain. The LINQ to SQL designer is small when it comes to large models. However, 35 tables are not very large.

If you can split tables in two or more groups, where each group is completely independent of the other (no relationship), in this case splitting is justified by IMO, especially when the groups are logically separated parts. In this case, you can give each context its own name.

However, when you have relationships between groups, this often indicates that they are part of the same domain. When splitting such a domain, this means that you will have to duplicate tables, which can be annoying and impractical, but when one model / context reads only this table, everything can be in order.

Also keep in mind that splitting a model can have some annoying side effects in your architecture. Of course, it depends on your architecture. The Ive application worked on using “service commands” that executed business logic on behalf of the presentation layer. The automatic design provided commands with an instance of the DataContext and had several DataContexts that made this project very frustrating.