Как эффективно создать динамический прокси для класса, содержащего почти 7000 открытых методов? - PullRequest
Новая
       32

Как эффективно создать динамический прокси для класса, содержащего почти 7000 открытых методов?

1 голос
/ 03 июля 2019

У меня есть класс, который автоматически генерируется с почти 7000 методов (не говоря уже о содержании или обосновании). Я хотел бы создать для него динамический прокси.

Мне известны два варианта:

  1. Время выполнения прокси с использованием RealProxy.GetTransparentProxy()
  2. Скомпилированный прокси, генерируемый во время выполнения с Castle.DynamicProxy.ProxyGenerator

Я хотел бы изучить второй вариант. И вот мой код: 

public class DynamicProxyFactory
{
    public static readonly DynamicProxyFactory Instance = new DynamicProxyFactory();

    private readonly ProxyGenerator m_generator;

    private DynamicProxyFactory()
    {
        m_generator = new ProxyGenerator();
    }

    public TInterface GetProxy<TInterface>(TInterface target, IInterceptor interceptor)
    {
        Assert.IsTrue(typeof(TInterface).IsInterface);
        var sw = Stopwatch.StartNew();
        try
        {
            return (TInterface) m_generator.CreateInterfaceProxyWithTargetInterface(typeof(TInterface), target, interceptor);
        }
        finally
        {
            Trace.WriteLine($"Dynamic proxy generation tool {sw.Elapsed}");
        }
    }
}

Код работает, но первоначальная стоимость генерации прокси довольно высока - он измеряется за считанные минуты. Я понимаю, 7000 методов - это не шутка.

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

1 Ответ

2 голосов
/ 05 июля 2019

Моим первым предложением было бы остановиться и попытаться отказаться от использования сгенерированного кода (особенно, если он создает чудовищность метода 7000). Серьезно.

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

В противном случае, если вы действительно настроены на использование DP, вы можете захотеть взглянуть на генерацию прокси во время сборки и сохранение сборки прокси. Я написал об этом учебник много лет назад . API теперь может немного отличаться, но основная структура и идея те же.

...