Justin Etheredge

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!



Re: LINQ Project General Real World Linq To SQL usage

Steve Strong

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





Re: LINQ Project General Real World Linq To SQL usage

Justin Etheredge

It would seem to me that having the ability to define namespaces on objects within a Linq To Sql file would for the most part solve the issue. This way I can specify that my Person entity is in a People namespace and my Item entity is in my Items namespace and since Linq To Sql would know the namespaces for everything it could generate the appropriate code. That way I could declare my partial classes anywhere I need to and not lose all my foreign keys and also not have to manage multiple contexts. Another thing to note is that it appears that the ADO.net entities stuff has the same issue, since it too appears to declare all of the partial classes in one namespace.





Re: LINQ Project General Real World Linq To SQL usage

Pratik Patel - MSFT

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.






Re: LINQ Project General Real World Linq To SQL usage

Daniel Simmons - MSFT

Just as a small clarification, Pratik's message above describes the support we are currently working on in the EntityFramework (Linq to Entities). It doesn't apply to Linq to SQL--but maybe the folks who are working directly on Linq to SQL now will have some suggestions. I'll move this thread over to the Linq forum where I think the relevant folks spend more of their time.




Re: LINQ Project General Real World Linq To SQL usage

Justin Etheredge

It would be fine with me to use either tool, and I am very glad to hear that at least Linq To Entities will be enabling this behavior! Thanks! Lets see if any of the Linq To Sql guys have any features up their sleeves.





Re: LINQ Project General Real World Linq To SQL usage

Anders Borum

Hi Justin

Just make sure you base your decision on LINQ to SQL / LINQ to Entities on the right information. There's a pretty big difference between the two frameworks and I wouldn't discard LINQ to SQL alone on the fact that it doesn't allow entites to span multiple namespaces (which I'm sure the LINQ to SQL developers would happily take as a feature request - even better, perhaps Matt's already working on it).






Re: LINQ Project General Real World Linq To SQL usage

Matt Warren - MSFT

We are already closed down for Beta 2. I might be able to convince everyone to do it before RTM.




Re: LINQ Project General Real World Linq To SQL usage

Justin Etheredge

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!





Re: LINQ Project General Real World Linq To SQL usage

cverdon

Hi,

Is there any word on whether this feature will make it to the rtm
It's not mentioned here but the generated context class should follow the namespace:

from e in db.HR.Employees
from p in db.Catalog.Products

Thanks,
Charles




Re: LINQ Project General Real World Linq To SQL usage

arielsan

Hi, i make some separation between namespaces, but keeping the associations by the foreign keys and only one data context, i mean, various dbml's and all with the same "partial" class for the data context.

It is some kind of work around for the "problem" or the "uncapability".
To do this, i make various dbml, all with the entity namespaces that i want, and the entities that i want.

Next, all the datacontext are the same, and the same namespace for that datacontext (to indicate the same partial class).

Next, for all the entitites i want associations, make all "by hand" (copy paste from the original dbml where alllll the entities were).

And... volia

Note: the generator generate the same definitions for the data contexts, we have to remove those items.

I know, i know, there is not a very beautiful solution, but, it solves some of the problems Wink




Re: LINQ Project General Real World Linq To SQL usage

Matt Warren - MSFT

There is a feature in RTM that allows you to specify different namespaces for the DataContext and the entities. However, there is no longer a feature that simulates namespaces on the context as there was in the original prototype. What will happen is that the names of tables will include their schema. So instead of db.HR.Employees you'll have db.HR_Employees.