Я знаю, это, вероятно, выигрывает награду за самый длинный и самый запутанный вопрос названия.Позвольте мне объяснить ...
Я пытаюсь реорганизовать длительный пакетный процесс, который, прямо скажем, сейчас крайне уродлив.Вот несколько подробностей о жестких спецификациях:
Процесс должен выполняться несколько раз (т. Е. В десятках тысяч);
Каждыйэкземпляр процесса выполняется на своем «активе», каждый со своими уникальными настройками;
Один процесс состоит из нескольких подпроцессов, и каждый подпроцесс требует своего срезаиз настроек актива, чтобы сделать свою работу.Группы не являются взаимоисключающими (то есть некоторые настройки требуются несколькими подпроцессами).
Весь пакет занимает очень много времени для завершения;таким образом, отдельный процесс довольно чувствителен ко времени, и производительность на самом деле гораздо более важна, чем чистота проектирования.
Что сейчас происходит, по сути, так это то, что для данного экземпляра актива / процесса,объект «Контроллер» считывает все настройки для этого актива из базы данных, помещает их все в строго типизированный класс настроек и запускает каждый подпроцесс индивидуально, передавая ему любые необходимые настройки.
проблемы с этим многочисленны:
- Существует более 100 отдельных настроек, что делает класс настроек сгустком грязи;
- Контроллер несет слишком большую ответственность и возможность ошибок
- Некоторые подпроцессы принимают более 10 аргументов конструктора.
Поэтому я хочу перейти к дизайну, основанному на внедрении зависимостей, путем свободной группировки настроек вразличные сервисы и позволяющие подпроцессам подписываться на те сервисы, которые им нужны через конструкторпрогиб.Таким образом, я смогу практически исключить раздутый контроллер и настройки классов.Я хочу иметь возможность писать отдельные компоненты, например, так:
public class SubProcess : IProcess
{
public SubProcess(IFooSettings fooSettings, IBarSettings barSettings, ...)
{
// ...
}
}
Проблема, конечно, в том, что «настройки» являются специфическими для данного актива, поэтому это не так просто, как просто зарегистрировать IFooSettings в IoC.Инжектор каким-то образом должен знать о , который IFooSettings он должен использовать / создавать.
Кажется, у меня остается два одинаково непривлекательных варианта:
Напишите каждый метод IFooSettings, чтобы получить идентификатор актива и передать идентификатор актива каждому подпроцессу.Это на самом деле увеличивает связь, потому что сейчас подпроцессам не нужно ничего знать о самом активе.
Создать новый контейнер IoC для каждого полногоэкземпляр процесса, передавая идентификатор ресурса в конструктор самого контейнера , чтобы он знал, для какого ресурса нужно получить настройки.Это похоже на серьезное злоупотребление контейнерами IoC, и я очень беспокоюсь о производительности - я не хочу идти и реализовывать это и выяснить, что это превратило 2-часовой процесс в 10-часовой.
Есть ли другие способы добиться дизайна, на который я надеюсь?Какой-то шаблон дизайна, о котором я не знаю?Какой-нибудь хитрый прием, который я могу использовать, чтобы заставить контейнер вводить нужные мне настройки в каждый компонент, основываясь на некоторой контекстной информации, без необходимости создания экземпляров 50 000 контейнеров?
Или, альтернативнодействительно ли нормально создавать экземпляры такого количества контейнеров в течение длительного периода времени?Кто-нибудь сделал это с положительными результатами?