HI, Currently i have one big datacontex with 35 tables (i dragged all my DB tables to the designer). I must admit it is very comfortable cause i have ORM to my full DB and query with linq is easy and simple.
My questions are: 1. Would you consider it bad design to have one datacontext with 35 tables or should i split it to logic units? 2. Is there any performance penalties for using such a big datacontext?
Thanks, Pini.
There is a performance penalty, since its rebuilding the meta model for all the mappings every time you create a new context, but if you are monitoring this and its not causing you problems then I wouldn't worry about it.
I tend to only use DataContexts for very small projects that only need a handful of tables modeled, anything more than that and its easier in the long-run going with a more traditional and mature ORM like nHibernate in my opinion.
I can understand your pain. The LINQ to SQL designer isn't great when it comes to big models. However 35 tables is not really big.
When you can split the tables in two or more groups, where each group is completely independent of the other (no relations), in that case splitting is justified IMO, especially when the groups are logically separated parts. In that case you can give each context a proper name.
However, when you have relationships between the groups, it is often an indication that they are part of one domain. When splitting such a domain, it means you will have to duplicate tables, which can be annoying and unpractical, but when one model / context only reads that table, it could be okay.
Also be aware that splitting de model could have some annoying side effects in your architecture. Of course it depends on your architecture. An application I’ve worked on used ‘service commands’ that executed business logic on behalf of the presentation layer. An automatic construct supplied the commands with an DataContext instance, and having multiple DataContexts made that design quite frustrating.