Real World Linq To SQL usage
I have a quick question about how Linq to SQL might be used in a typical business layer of an application. In most business layers that I have seen the business objects are split up into several namespaces even though these objects may have references between each other. So you might have a namespace called Membership that has all of your objects related to users, roles, etc... and you might have another one called Tasks that relate to another aspect of your application.
From what I have seen, the recommended way of extending the objects generated by the Linq To Sql designer is to declare a partial class that contains all of your added methods. The issue is that this doesn't fit very well into the way that the classes are generated. The classes are put into the same namespace that the dbml file was in when the classes were generated. And since partial classes cannot span namespaces, this keeps me from implementing partial classes if I put the dbml in the root of my project and my partial classes in namespaces under it.
So I thought about having a dbml file for each namespace that only had the types that are in that namespace, but then you lose all of the nice foreign key relationships that are generated for you and you have a different context object for each set of tables. And if I try to put additional tables in there so that I can keep the references, then I end up with mutiple copies of each class in different namespaces.
So I guess this all leads to my final question of how exactly is it proposed that we use Linq in our projects. I am either missing something big, or I am going to have to put all of my business objects in one namespace (not liking this idea), or I am going to have to wrap all of the objects generated by the Linq to Sql designer so that I can have the implementations elsewhere. This will require a lot of repetitive code and maintenance issues, which is not really ideal. I'm sure this issue has been well thought out and I can't wait to hear people's suggestions!
I was also wondering about similar issues - we have just started planning on a project that makes heavy use of Linq to Sql, and are coming across similar issues. One that's hit us is whether to have one *big* .dbml file containing the whole database, or to have various smaller dbml files each containing well-defined subsets. We are currently going down the latter route, since it keeps things much cleaner (in particular, the ownership of each part of the system (and hence each file) is much easier to control). Having done that, we have however lost the foreign keys that exist between the different subsets, and also now have a whole bunch on contexts floating around - this is not a huge problem, but we do have to be careful to avoid opening up multiple database connections by mistake (which is what the default constructor on the context would do).
I'd also be interested in hearing folks opinion on this, and whether the Linq to Sql team have considered support for keys that span multiple models or any sort of uber-context concept?
For Beta2 of Ado.Net, we are adding this feature which allows one to refer types from different namespaces. In the example you gave, Person entity is in a People Namespace and Item entity is in Items namespace, and you can define a relationship between them (Person_Item) either in a third new namespace or in any one of the existing namespace. The code generation will generate these entities in different namespaces. Let me know if you have more questions about this and I will be glad to answer them.
Well, at least for us it is a deal breaker between Linq To Sql and ADO.net Entities. Without having Linq to SQL support objects spanning multiple namespaces it will make it very hard to use in large projects. From what I can tell though, this is where these products are aimed though. Linq To Sql at smaller scale projects and ADO.net entities at larger projects. Linq to Sql seems a bit more simple and would probably fill most of our needs, with the exception of forcing us to put all our objects in one namespace or give up foreign key relationships. If it would be possible to fit this in for RTM then I think that a lot of people would thank you. Thanks for the great product guys!
