Testing Multiple LIghtspeed Contexts

I tend to work with more than one context, reason being in large applications a single context get way too large to manage and becomes very annoying. In many cases my controllers need access to more than one unit of work, how do you suggest implementing this maintaining test-ability through dependency injection?

For exmaple, If have a controller that looks like the below how would I go about injecting a second unit of work belonging to a different context.

public class ProductController : Controller {

private readonly IUnitOfWork _productUnitOfWork;

public ProductController (IUnitOfWork productUnitOfWork)
{
     if (productUnitOfWork== null) throw new ArgumentNullException("productUnitOfWork");
     _productUnitOfWork= productUnitOfWork;
}

}

I'm using autofac for DI which is configure as

builder.RegisterInstance(new LightSpeedContext("Product") { VerboseLogging = true, Logger = new ConsoleLogger() }).As>().SingleInstance();

builder.Register(c => c.Resolve< LightSpeedContext< ProductModelUnitOfWork >>().CreateUnitOfWork()) .As< IUnitOfWork>().InstancePerLifetimeScope();

You would need to have two members in your controller class, one for each unit of work type (e.g. ProductUnitOfWork, CustomerUnitOfWork -- that is what you mean by 'context' isn't it?). I don't know how you would tell Autofac to initialise these in different ways but I assume it is possible, maybe using attributes or something? Or if you make the constructor arguments strongly typed e.g. ProductUnitOfWork instead of IUnitOfWork.

However, the dirty secret is that you don't actually need multiple units of work at all (unless you are talking to multiple databases). If you are using IUnitOfWork, then you will be performing queries using Find(QueryExpression) or the Query<T> extension method, and these are happy to work with any entity type, even one that doesn't have a LINQ wrapper property. The LINQ wrapper properties are only there as convenience helpers. For example, you can write _productUnitOfWork.Query<Customer>() even though ProductUnitOfWork does not have a Customers property.

That's the way I initially setup my solution but found it difficult to test using a strongly typed unit of work. The autofac part is fine, it doesn't have to be an interface that is injected. Could you provide a quick unit test example on a strongly typed unit of work, whats the best way to do this?

By context I was meaning different Models and possibly different databases. I didn't realise that entities from any model could be accessed through the same unit of work (provided they use the same lightspeed context or database), that seems obvious now :)

I'm not quite sure what you're asking for in terms of a unit test example. For our unit tests, we use a database which we recreate at the beginning of each test run, and perform each test within its own transaction (via the setup/teardown methods) so that the database remains in the same state for each test. Are you asking about faking/mocking a unit of work?

Yes, mocking a strongly typed unit of work.

Ah, gotcha. Unfortunately this is not directly possible because the generated XxxUnitOfWork classes inherit from UnitOfWork. You can work around it by creating an interface for your strong-typed unit of work and implementing it on the concrete XxxUnitOfWork class:

public interface IProductUnitOfWork : IUnitOfWork {
  IQueryable<Products> { get; }
}

partial class ProductUnitOfWork : IProductUnitOfWork { }  // no implementation, generated properties will fulfil interface

Then use the interface instead of the concrete class for your dependency injection.

The obvious downside of this is maintenance, and you should be able to alleviate that by tweaking the LightSpeed code gen templates to generate the interface type for you. If you want to do this, you will probably be able to figure out how by looking at the DataContext.vm file, but if you need more info, let us know.

Forgot to mention -- there is also a designer option to emit the query properties as virtual, which would allow them to be mocked. Depending on your test strategy this is probably an easier option than mucking around with custom templates!

This is a stealth option at the moment so to use it you must open the .lsmodel file in a text editor and add the following attribute to the model element:

<model codeGenerationOptions="VirtualQueryProperties">

Then close the text editor, reopen the .lsmodel file in Visual Studio and regenerate the code.

I did think about putting an interface on my unit of work as you suggested but yes didn't want to be changing this whenever I changed my model. If I can modify the LightSpeed code gen templates that may be the way to go for me. Thanks for your help.