Li todo esse tópico duas vezes e acho que as pessoas estão respondendo pelo que sabem, não pelo que é solicitado.
A pergunta original do JP parece que ele está construindo objetos enviando um resolvedor e, em seguida, um monte de classes, mas estamos assumindo que essas classes / objetos são serviços, propensos a injeção. E se eles não forem?
JP, se você estiver buscando alavancar o DI e desejar a glória de misturar injeção com dados contextuais, nenhum desses padrões (ou supostos "antipadrões") trata especificamente disso. Na verdade, tudo se resume ao uso de um pacote que o apoiará nesse esforço.
Container.GetSevice<MyClass>(someObject1, someObject2)
... este formato raramente é suportado. Acredito que a dificuldade de programar esse suporte, somada ao desempenho miserável que seria associado à implementação, torna pouco atraente para os desenvolvedores de código aberto.
Mas isso deve ser feito, porque eu devo ser capaz de criar e registrar uma fábrica para o MyClass'es, e essa fábrica deve receber dados / entradas que não são levados a ser um "serviço" apenas para passar dados. Se "antipadrão" é sobre consequências negativas, forçar a existência de tipos de serviços artificiais para transmitir dados / modelos é certamente negativo (a par do seu sentimento de agrupar suas classes em um contêiner. O mesmo instinto se aplica).
Existem estruturas que podem ajudar, mesmo que pareçam um pouco feias. Por exemplo, Ninject:
Criando uma instância usando Ninject com parâmetros adicionais no construtor
Isso é para .NET, é popular e ainda não está tão limpo quanto deveria ser, mas tenho certeza de que há algo em qualquer idioma que você escolher empregar.