StructureMap - внедрение зависимости в базовый класс?

Question

В моем домене у меня есть несколько «процессорных» классов, которые содержат основную часть бизнес-логики. Используя StructureMap с соглашениями по умолчанию, я внедряю репозитории в эти классы для их различных операций ввода-вывода (базы данных, файловая система и т. Д.). Например:

public interface IHelloWorldProcessor
{
    string HelloWorld();
}
public class HelloWorldProcessor : IHelloWorldProcessor
{
    private IDBRepository _dbRepository;
    public HelloWorldProcessor(IDBRepository dbRepository)
    {
        _dbRepository = dbrepository;
    }
    public string HelloWorld(){ return _dbRepository.GetHelloWorld(); }
}

Теперь есть несколько репозиториев, которые я хотел бы сделать доступными для всех процессоров, поэтому я создал такой базовый класс:

public class BaseProcessor
{
    protected ICommonRepository _commonRepository;
    public BaseProcessor(ICommonRepository commonRepository)
    {
        _commonRepository = commonRepository;
    }
}

Но когда другие мои процессоры наследуют его, я получаю сообщение об ошибке компилятора о том, что нет никакого конструктора для BaseProcessor, который принимает нулевые аргументы.

Есть ли способ сделать то, что я пытаюсь сделать здесь? То есть иметь общие зависимости, внедренные в базовый класс, которые могут использовать мои другие классы, не записывая инъекции в каждый из них?

Answer 1

Нет. Это требование языка C #, а не ограничение StructureMap. Производный класс должен передавать значения своим базовым конструкторам. Если вы используете базовый класс исключительно для управления внедрением общего сервиса, вы ничего не получите. Просто установите общий сервис для каждого класса, который в этом нуждается - ваш инструмент IoC позаботится об этом - какой вред?

Answer 2

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

Ответ здесь заключается в том, чтобы избежать этой явной слабости при внедрении конструктора и использовать внедрение свойства в базовом классе.