Prefetching data in with Linq-to-SQL, IOC and Repository pattern

Question

Hi,

using Linq-to-SQL I'd like to prefetch some data.

1) the common solution is to deal with DataLoadOptions, but in my architecture it won't work because :

• the options have to be set before the first query
• I'm using IOC, so I don't directly instanciate the DataContext (I cannot execute code at instanciation)
• my DataContext is persistent for the duration of a web request

2) I have seen another possibility based on loading the data and its childs in a method, then returning only the data (so the child is already loaded) see an example here

Nonetheless, in my architecture, it cannot not work :

• My queries are cascaded out of my repository and can be consumed by many services that will add clauses
• I work with interfaces, the concrete instances of the linq-to-sql objects do not leave the repositories (yes, you can work with interfaces AND add clauses)
• My repositories are generic

Yes, this architecture is quiet complicated, but it's very cool as I can play with the code like lego ;)

My question is : what are the other possibilities to prefetch a data ?

Answer 1

I'm not aware of other possibilities, it seems like you've pushed LinqToSql to its limits (I may be wrong, however).

I think your best options at this point are:

1. Add some "non-generic" methods to your application to handle just the specific scenarios where you want/need eager loading and don't use your "normal", "generic" infrastructure for those methods.
2. Use an ORM that has more sophisticated support for eager and lazy loading.

Answer 2

I found a solution. My answer is 'Dependency injection'.

It's generally shipped with IOC, and mean you can have your IOC container manage injection of classes at instanciation.

All I need is to inject a CustomDCParameter class when I instanciate a DC. That class will contains the rules, and the constructor will apply all of them.

Answer 3

This might be a solution to the DataLoadOptions and seems similar to your posted answer with regard to DI-

This is how i create my DataContext in my DAL:

public class SqlRepositoryRegistry : Registry
{
    public SqlRepositoryRegistry()
    {
        string dbConnStr = String.Empty;
        if (ConfigurationManager.AppSettings["ActiveDbConnectionString"] == null ||
            ConfigurationManager.AppSettings["ActiveDbConnectionString"] == "KsisOnline2_local")
        {
            // must be running tests - so use local
            dbConnStr = DataAccessConstants.CONNSTR_LOCALINTTESTS;

            ForRequestedType<LinqKsisOnline2DataContext>()
                .TheDefault.Is.ConstructedBy(
                    () => new LinqKsisOnline2DataContext(dbConnStr) { Log = new MattyLib.Diagnostics.DebuggerWriter() }
                );
        }
        else
        {
            dbConnStr = ConfigurationManager.ConnectionStrings[ConfigurationManager.AppSettings["ActiveDbConnectionString"].ToString()].ConnectionString;

            ForRequestedType<LinqKsisOnline2DataContext>()
                .TheDefault.Is.ConstructedBy(
                    () => new LinqKsisOnline2DataContext(dbConnStr)
                );
        }

        ForRequestedType<LinqKsisOnline2DataContext>()
            .CacheBy(InstanceScope.Hybrid);
    }
}

..if you're familiar with StructureMap you'll recognise the 'Registry' class design. It's a lot of example, but the point is simple - i can control exactly how i instantiate my dc even when i'm using DI. You can see i want to do things differently when i'm running tests - so i can get verbose logging output from LinqToSql.

Answer 4

I actually prefer this solution however:

In my app i use perhaps a variation to your potential solution #2. It's somewhat difficult to explain but simply: i chain and defer lazy loading in my model with custom lazy classes so as to abstract away from the LinqToSql-specific Differed Execution that i take advantage of with IQueryable. Benefits:

• My Domain Model and Service layer upwards does not necessarily have to depend on the LinqToSql provider (i can swap out my DAL with interfaces if i want to)
• My Service methods can and do return complete object graphs with multiple 'anchor points' for lazy loading using classes that abstract away a particular lazy loading implementation - so i can use LinqToSql-specific Differed Execution or something else (eg. anon delegates. again, refer to this answer)
• I can maintain IQueryable results throughout my app (even to the UI if i want to) thus allowing infinite LINQ query chaining without having to worry about performance.