Я немного углубился в то, как вы можете расширить Unity для этой цели, и нашел некоторую интересную информацию.
Во-первых, кажется, что Unity выбирает, какой конструктор использовать, внутренним разрешением IConstructorSelectorPolicy
.В Unity входит public abstract class ConstructorSelectorPolicyBase<TInjectionConstructorMarkerAttribute>
, который включает в себя этот гем:
/// <summary>
/// Choose the constructor to call for the given type.
/// </summary>
/// <param name="context">Current build context</param>
/// <param name="resolverPolicyDestination">The <see cref='IPolicyList'/> to add any
/// generated resolver objects into.</param>
/// <returns>The chosen constructor.</returns>
public SelectedConstructor SelectConstructor(IBuilderContext context, IPolicyList resolverPolicyDestination)
{
Type typeToConstruct = context.BuildKey.Type;
ConstructorInfo ctor = FindInjectionConstructor(typeToConstruct) ?? FindLongestConstructor(typeToConstruct);
if (ctor != null)
{
return CreateSelectedConstructor(context, resolverPolicyDestination, ctor);
}
return null;
}
FindInjectionConstructor
, и компания является private static
методами в этом классе, которые в конечном итоге вызывают Type.GetConstructors
(перегрузка без параметров, который возвращает только public
конструкторы).Это говорит мне о том, что если вы можете организовать для Unity собственную политику выбора конструкторов, которая сможет выбирать любого конструктора, вы великолепны.
Есть хорошая документация о том, каксоздавать и использовать свои собственные контейнерные расширения, поэтому я полагаю, что вполне возможно сделать свой собственный CustomConstructorSelectorPolicy
, который включает в себя соответствующие части DefaultUnityConstructorSelectorPolicy
(который происходит от абстрактного базового класса и является значением по умолчанию, если только вызарегистрировать что-нибудь еще) и ConstructorSelectorPolicyBase
(производное от этого напрямую, вероятно, не будет работать хорошо, потому что ключевые методы не virtual
, но вы можете повторно использовать код).
Поэтому я 'Я бы сказал, что это выполнимо с небольшим количеством хлопот, но конечный результат будет довольно "чистым" с инженерной точки зрения.