2009-11-17 1 views
1

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

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

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 для других вещей. nyway. Мне нравится, что он дает членам команды соглашение для заводов вместо того, чтобы просто позволить им крыло (создавая кучу разных заводских классов в странных местах или просто ставя статические методы на объекты и т. Д.).

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

ответ

5

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

+0

Многое лучше. Где-то мой мозг попался между инъекцией зависимости и инъекцией фабрики. Благодарю. –

 Смежные вопросы

  • Нет связанных вопросов^_^