none
simple LINQ to SQL design suggestion RRS feed

  • General discussion

  • Linq to SQL is great for small projects and I want to say thanks for this addition to the BCL, but I do have one suggestion that would make using the framework in slightly larger small projects.

    This situation I have is a medium sized application where the data access logic is contained in a single assembly, say DataAccess.dll.  The application connects to multiple data sources (including a sql server database, a db2 database, and an exchange data store).  The idea here is to allow a facade class to hide all the complexity of accessing data from several sources and provide a simple interface for getting / persisting POCO domain objects to the rest of the app.

    I really wanted to use LINQ to SQL for the SQL Server portion, but I wanted to encapsulate the use of LINQ to SQL inside DataAccess.dll. I want to make sure that assemblies that depend on DataAccess.dll don't have to also depend on System.Data.Linq.  It was very straightforward to make a wrapper for the DataContext, however, the generated classes expose foreign key constraints as EntitySet<T> and there is no way to make the code generator declare them as ICollection<T> or IEnumerable<T>.

    For now, I just made sure that all the entity sets are declared private and write my own property accessors that are typed appropriately.  It works fine, but the whole reason I wanted to use LINQ to SQL for this part was to be able to generate most everything automatically and customizing all of those partial classes requires a fair amount of hand-coding.

    Could we get a new option in the dbml or mapping file that would cause the code generator to generate foreign key constraints as one of the interfaces already implemented by EntitySet<T>?  This would go a long way to making generated classes usable without depending on System.Data.Linq or modifying every single one of them.
    Tuesday, March 18, 2008 10:19 PM

All replies

  • Nick, foreign key constraints are of EntitySet<T> type because they support delayed loading. We can change the "Delay Loading" for properties to true or false, but we have no such an option for foreign keys.
    For example, when you change the "Delayed Loading" to true for a string property it's type changes to System.Data.Linq.Link<string>.

    I think it would be great if we had a "Delayed Loading" boolean property for foreign keys too. So if delayed loading was switched off, the foreign key type would be IEnumerable<T>. It would be nice.

    Nick, do you think EntitySet properties are necessary at DAL layer? I want to find a safe way to delete foreign keys from the autogenerated classes, because I think they are needless. If we use delayed loading, data will be loaded out the data-layer and I don't like. If not to use delayed loading, EntitySets use a lot of traffic and I think it's better to organize foreign keys by hands when you need. What do you think about it?
    Wednesday, March 19, 2008 8:07 AM
  • I think this article will be interesting for you.
    So we can use other types for associations but we loose delayed loading.
    Thursday, March 20, 2008 5:38 PM