Использование ядра Ninject в качестве фабрики объектов Unit of Work - PullRequest
Новая
       11

Использование ядра Ninject в качестве фабрики объектов Unit of Work

1 голос
/ 17 ноября 2009

Итак, я начинаю использовать Ninject для внедрения зависимостей, и мне интересно, что люди думают об использовании ядра в качестве фабрики объектов для объектов типа Unit of Work, таких как Linq2Sql Datacontexts. Я бы просто внедрил их как обычные зависимости, но это приводит к некоторым проблемам времени жизни объекта, которых я бы хотел избежать. DataContexts отличаются от общих зависимостей, потому что вы должны раскручивать новые экземпляры по мере необходимости и избавляться от них, когда закончите.

Чтобы сделать что-то подобное, я бы просто настроил провайдера, например ... 

class SomeDataContextProvider : Provider<SomeDataContext>
{
    private static string _connectionString = "someConnectionString"
    protected override SomeDataContext CreateInstance(IContext context)
    {
        return new SomeDataContext(_connectionString);
    }
}

Свяжите их в модуле ... 

class MyModule : Ninject.Modules.NinjectModule
{
    public override void Load()
    {
        Bind<SomeDataContext>().ToProvider(SomeDataContextProvider);
    }
}

И при необходимости используйте стандартное ядро ​​... 

class MyClassThatNeedsADataContext
{
    private StandardKernel _kernel = new StandardKernel(new MyModule());

    public void SomeMethod()
    {
        using (var db = _kernel.Get<SomeDataContext>())
        {
            //Use the context
        }
    }
}

Это кажется немного тяжелым для того, что по сути является статической фабрикой, но я все равно использую Ninject для других вещей. Мне нравится, что он дает членам команды соглашение для фабрик, вместо того, чтобы просто позволять им использовать его (создавая кучу разных фабричных классов в странных местах или просто помещая статические методы в объекты и т. Д.).

Мысли? Есть ли лучший способ справиться с зависимостями Unit of work, такими как DataContexts или WCF Service Clients, используя внедрение зависимостей?

1 Ответ

5 голосов
/ 17 ноября 2009

Мне не нравится внедрять контейнеры в классы, так как это создает зависимость между вашим приложением и контейнером и делает менее понятным, какие зависимости есть у класса. На самом деле я не понимаю, как этот подход приносит вам какую-то выгоду по сравнению с фабрикой, поэтому лично я создал бы «DataContextFactory» и вставил бы его во все классы, которым требуется доступ к базе данных.

...