Как ввести изменяющуюся зависимость

Question

Я новичок в инъекции зависимостей, мне интересно, как бы вы справились со следующим сценарием. У нас есть что-то вроде следующего:

public class DatabaseContext 
{ 
    public string ConnectionString {get;} 
} 

public interface IDataAccess 
{ 
    string GetString(int id); 
} 

public class DataAccessImpl : IDataAccess 
{ 
    private DatabaseContext _context; 
    public DataAccessImpl(DatabaseContext context) 
    { 
    this._context=context; 
    } 

    public string GetString(int id) 
    { 
    return "some data"; 
    } 
} 

Для веб-приложений, каждый запрос может построить до другого DatabaseContext, чтобы указать на другую базу данных. Для оконных форм мы можем изменить текущий DatabaseContext. Каким образом di framework обрабатывает зависимость, которая может измениться? Таким образом, когда я запрашиваю IDataAccess, он всегда имеет соответствующий/текущий DatabaseContext.

Answer 1

Подход, который я принял, заключается не в том, чтобы вводить DataContext, а в фабрику DataContext, класс с методом, который возвращает DataContext соответствующего типа. У меня есть два конструктора, в моем случае, класс контроллера - конструктор по умолчанию и тот, который принимает фабрику (и другие введенные объекты). Конструктор по умолчанию просто вызывает конструктор с параметрами со всеми параметрами null. Параметрированный конструктор создает объекты по умолчанию, если соответствующий параметр имеет значение null.

Использование фабрики позволяет моим действиям контроллера создавать новый DataContext при вызове вместо одного DataContext, который существует на протяжении всего срока службы приложения. Завод может быть построен, чтобы вернуть существующий контекст, если он есть, и создать новый по мере необходимости, но я предпочитаю охватить их частью работы.

P.S. Завод фактически создает класс оболочки вокруг DataContext, а не фактический DataContext, как интерфейс (IDataContextWrapper). Это значительно упрощает издевание фактической базы данных из моих тестов контроллера. Все вышеперечисленное предполагает LINQ/ASP.NET MVC, но принципы, как правило, применимы, я думаю.