(apologies for the Wall Of Text... :) )

Summary

Using Dependency Injection with my Winfor application is creating a large number of Repository Context's. I'm not sure if the way i'm using this is right or wrong, or what the common practice is.

Details

In the last 6 odd months, I've been making ASP.NET MVC applications that impliment the Unit O fWork pattern with the Repository Pattern. On top of this, I've been using an Dependency Injection on all of these web applications with some success.

So this is an example of me wiring up my repository.

public EntityFrameworkRepositoryRegistry() 
{ 
    For<IUnitOfWork>() 
            .HybridHttpOrThreadLocalScoped() // Lifecycle of the object.
            .Use<SqlServerContext>()  // My EF Context.
            .Ctor<string>("connectionString").Is("name=SqlServer_EF")
            .Ctor<string>("defaultContainerName").Is("Entities"); 
 
    // Ayende's EFProf application :) 
    EntityFrameworkProfiler.Initialize();      

    Scan(x => 
        { 
            x.TheCallingAssembly(); 

            x.ExcludeNamespaceContainingType<Fake.FakeContext>(); 

            x.WithDefaultConventions(); 
        } 
    );    
} 

Ok - works great. Main thing to note here is that

  • I'm assuming the Lifecycle is the correct one for a Web scenario.
  • The context will only exists once, per REQUEST that hits the webserver.

kewl.

Now, for my WinForm application, i initially created a single Unit Of Work object (no dependency injection, just yet) and kept passing that baby around to all the services (and then to the repositories).

For this win application, it hits the DB to find out all the text files it needs to parse. (eg. 25 files). Then, for each file, it creates a new Parser, reads each line and chucks the parsed data into a db table. Fine.

Pro

Edit
Report