Dependency Injection doesn't work if you half ass it only take it half way. Consider this ctor.

    #region Constructor
    public UnitOfWork(IAggregatorContext context)
    {
        this._context = context;

        LexemRepository = new Lazy<IRepository<Lexem>>(() => new Repository<Lexem>(context));
        WordRepository = new Lazy<IRepository<Word>>(() => new Repository<Word>(context));
        SynsetRepository = new Lazy<IRepository<Synset>>(() => new Repository<Synset>(context));
    }

You inject the IAggregatorContext, but not the various repositories your UnitOfWork requires. You should also be ctor injecting all of these dependencies, and using Ninject to bind them. If you can't inject it, you can't mock it, and right now you can't do either with your repositories.

Your method of obtaining a database connection string is misguided. If something is hard, it's usually because you're going about it the wrong way. Just use the data context ctor overload that takes in a connection string.

I wanted to talk about your using Ninject as a service locator, but I can't even begin to describe how bad ArticleParserProvider is. I don't even know what it is that you're trying to do here. In order to fix this up, you'll need to take a few steps.

1. Replace every instance of new with an instance that gets injected through the constructor. If you need it to be short lived, pass a factory class instead.

The number of arguments each ctor takes will grow as you go up the chain towards your composition root. That's okay, and in fact, is a Good Thing™. 2. Don't pass anything from Ninject to anything else. Once you get all of your dependencies up and into your composition root, then bind them all with Ninject. Let the IoC do it's magic and recurse down the dependency tree.

Here's the thing about IoC containers... You don't need them. They just make our code near the root easier to read and deal with. Write your code so that it doesn't know that there even is an IoC container. When you're done, you should be able to create and run an instance of your program using any container, even one that we hand write into the composition root.

Dependency Injection doesn't work if you half ass it only take it half way. Consider this ctor.

    #region Constructor
    public UnitOfWork(IAggregatorContext context)
    {
        this._context = context;

        LexemRepository = new Lazy<IRepository<Lexem>>(() => new Repository<Lexem>(context));
        WordRepository = new Lazy<IRepository<Word>>(() => new Repository<Word>(context));
        SynsetRepository = new Lazy<IRepository<Synset>>(() => new Repository<Synset>(context));
    }

You inject the IAggregatorContext, but not the various repositories your UnitOfWork requires. You should also be ctor injecting all of these dependencies, and using Ninject to bind them. If you can't inject it, you can't mock it, and right now you can't do either with your repositories.

Your method of obtaining a database connection string is misguided. If something is hard, it's usually because you're going about it the wrong way. Just use the data context ctor overload that takes in a connection string.

I wanted to talk about your using Ninject as a service locator, but I can't even begin to describe how bad ArticleParserProvider is. I don't even know what it is that you're trying to do here. In order to fix this up, you'll need to take a few steps.

1. Replace every instance of new with an instance that gets injected through the constructor. If you need it to be short lived, pass a factory class instead.

   The number of arguments each ctor takes will grow as you go up the chain towards your composition root. That's okay, and in fact, is a Good Thing™.

2. Don't pass anything from Ninject to anything else. Once you get all of your dependencies up and into your composition root, then bind them all with Ninject. Let the IoC do it's magic and recurse down the dependency tree.

Here's the thing about IoC containers... You don't need them. They just make our code near the root easier to read and deal with. Write your code so that it doesn't know that there even is an IoC container. When you're done, you should be able to create and run an instance of your program using any container, even one that we hand write into the composition root.