Dependecy problems

Hello! I want to build an ASP.NET MVC 3 app, which have to meet next requirements:

1. Database engine independency. Which means, I want to use MySQL or MSSQL or even SQLite, depending on application configuration. Of course, I will have a set of repositories per DB engine, but they (repositories) will share the same interface and return POCOs, which will be used in controllers and views.

2. Each instance of application will have multiple contexts, 3 or 4, I guess. These contexts may use databases from p. 1.

3. Unit of work per context per request.

4. Mono compability (if possible)

What I have so far:

1. Repositories that accept strongly-typed UnitOfWorkScope as a constructor parameter.

2. PerRequestUnitOfWorkScopes that accept strongly-typed contexts as a constructor parameters.

3. Unity as a dependency resolver.

A problem here, is that I can't figure out, how to inject that strongly-typed UnitOfWorkScope into repository, keeping myself independent from conrete UnitOfWork.

Hmm, not sure I understand the question here. It sounds like the issue is about how to get Unity to resolve the constructor dependencies for PerRequestUnitOfWorkScope<T> (on LightSpeedContext<T>) and for your repository class (on UnitOfWorkScope<T>), rather than about the LightSpeed classes themselves. Is that correct? If so, you may have more luck on a Unity forum (we're not particularly familiar with Unity).

Of course, if your problem is more about specifics of LightSpeed that make it hard to inject dependencies using Unity, we'll be happy to help out, but you'll have to tell us a bit more about where you're running into problems and what Unity assumes/requires that is causing difficulties with the LightSpeed API.

This is solved easily, but you have to use some indirection.

For example, you want a generic repository pattern, but you want LightSpeed to generate the models, unit of work, and then you want to obviously specify how your repository can be injected, right?

There are many, many examples of how to do this on the web, look in particular at the NCommon project I think.

Here is a little bit of how I do it.

public interface IDbRepository<TUnitOfWork> : IRepository, IDisposable where TUnitOfWork : IUnitOfWork

look in particular at IRepository, and IUnitOfWork interfaces, they come from LightSpeed, but I am defining my own specific repository pattern in this interface.

public abstract class DbRepositoryBase<TUnitOfWork> : RepositoryBase<TUnitOfWork>, IDbRepository<TUnitOfWork>

then I use a base class which implements the interfaces and works directly with the LightSpeed api.

public interface IMyAppDbRepository : IDbRepository<MyAppModelUnitOfWork>

For my application, I then define an additional interface which provides the indirection needed for dependency injection for a repository of a specific database.

public class MyAppDbRepository : DbRepositoryBase<MyAppModelUnitOfWork>, IMyAppDbRepository

Then I create a concrete implementation of the repository of the specific application database.

public MyController(IMyAppDbRepository dbRepository)

Lastly, in the constructor of my MVC controllers, I can now reference which specific repository is needed. But, in my code I am simply using the original IDbRepository generic interface which I showed at the beginning.

This method decouples me from LightSpeed if needed, but believe me it hasn't been a problem, and gives me flexibility to use my generic repository pattern with specific LightSpeed models and database configurations.

As I mentioned, there are many, many implementations that are probably far better than mine, but this works well for me. I do recommend going with a different container, I use StructureMap and it gives me much more flexibility than Unity did.

Good luck,

Jeff

Thank you for you reply, Jeff. Your solution is quite clear except one thing. I still can't fully understand how to decouple myself from concrete UoW. Can you, please, provide little example which shows, where and how strongly-typed UoW injected into repository?

I am sorry, but my code implementation is confidential as I work for a commercial software company.

But answering your question, your application code can be insulated by defining methods in your custom IMyAppRepository interface. Typically, I use a generic GetAll<TEntity> method which under the hood calls my concrete LightSpeed UoW to return an IQueryable on TEntity. From there, all my application does is use Linq statements to perform the query. You never inject the UoW, only the IMyAppRepository! You should always pass the LightSpeed UoW as part of the constructor to any repositories that you create. This is how and where the decoupling occurs.

So, your application is decoupled by using any custom repository interfaces and those concrete implementations that you provide do utilize the LightSpeed generated UoW. It's kind of like the best of both worlds since the repository has full access to the LightSpeed API you can really do anything you need. If you need a capability exposed, just expose it using a method. In honesty, I haven't needed to do that yet as the IQueryable implementation in LightSpeed is really good.

If you need more complete examples, I suggest googling for things like "Generic Repository IQueryable" on google. If you are new to dependency injection patterns, you may want to read up on that first else risk not fully understanding what you are trying to accomplish in your repository implementation.

Best regards,

Jeff

Hi Jeff,

I like your approach and tried it out with Lightspeed 4, but unfortunately it does't work with step 2:

public abstract class DbRepositoryBase<TUnitOfWork> : RepositoryBase<TUnitOfWork>, IDbRepository<TUnitOfWork>

gives me following compile errors:

The type 'TUnitOfWork' cannot be used as type parameter 'TUnitOfWork' in the generic type or method 'Console.IDbRepository'. There is no boxing conversion or type parameter conversion from 'TUnitOfWork' to 'Mindscape.LightSpeed.IUnitOfWork'.

'TUnitOfWork' must be a non-abstract type with a public parameterless constructor in order to use it as parameter 'TUnitOfWork' in the generic type or method 'Mindscape.LightSpeed.RepositoryBase

Have you an idea why this doesn't work for me?

Many thanks in advance.

Best regards, Tom

'

Hi Jeff,

could it be that your definition of DbRepositoryBase looks like this:

  public abstract class DbRepositoryBase<TUnitOfWork> : RepositoryBase<TUnitOfWork>, IDbRepository<TUnitOfWork> where TUnitOfWork : class, IUnitOfWork, new()
  {
    protected DbRepositoryBase(UnitOfWorkScopeBase<TUnitOfWork> unitOfWorkScope) : base(unitOfWorkScope)
    {
    }

    public void Dispose()
    {
      UnitOfWorkScope.Dispose();
    }
  }

Best regards, Tom

Hi Tom,

Yes, that's exactly right.

public abstract class DbRepositoryBase<TUnitOfWork> : RepositoryBase<TUnitOfWork>, IDbRepository<TUnitOfWork>
    where TUnitOfWork: class,IUnitOfWork,new() {

    protected DbRepositoryBase(UnitOfWorkScopeBase<TUnitOfWork> unitOfWorkScope)
        : base(unitOfWorkScope)
    {
    }
}

Regards,

Jeff

Hi Jeff,

but, then I don't understand how you register the DBRepositoryBase with the UnitOfWorkScopeBase in the IoC. If the IoC is capable of HttpRequestLifeCycles you won't need the UnitOfWorkScopBase. Then a simple UnitOfWork would be enough. The Lifecycle of this could be handled by the IoC.

Best regards, Tom

Not everything needs to be handled as a dependency in the IoC. My top-level repositories take a generated LightSpeed Context which I set as a constructor argument when I bind it using the IoC. That constructor then passes a SimpleUnitOfWorkScope down to DbRepositoryBase.

I only DbRepositoryBase as a pattern for consistency, many would argue that it is an unnecessary anti-pattern, but it works well for what I am trying to accomplish within the codebase. Obviously, to get an actual concrete repository implementation using LightSpeed, you must pass a LightSpeed context somewhere. The good thing, is that you will know which Context will go with which repository and you can bind the IoC container appropriately.

Your implementation and mileage may vary, but it works well for me.

Jeff