, когда выполняется код AOP

Question

Я прочитал несколько статей об АОП, и это выглядит очень интересным и мощным инструментом.

Но как насчет производительности?

Например, что, если я создам атрибут аспекта, называемый MyMethodAspect. Это было бы просто: в начале метода извлечения с этим атрибутом называется кодом, содержащимся в моем классе MyMethodAspect. Например, напишите строку текста - «start ...»

это основной пример - но что делать, если логика, выполняемая при запуске метода, намного сложнее. Могу ли я понять, что код, выполняемый при запуске метода, скомпилирован только один раз, а позже AOP не потребует дополнительной мощности?

C#:

public void Do(int x){ 
Console.WriteLine(x); 
} 

я себе IL-то вроде (в значительной степени то же самое):

public void Do(int x){ 
    Console.WriteLine(x); 
    } 

и аспект:

C#:

[MyMethodAspect] 
    public void Do(int x){ 
    Console.WriteLine(x); 
    } 

, так что я полагаю, что IL является somet повесят как:

public void Do(int x){ 
Console.WriteLine("starting..."); 
    Console.WriteLine(x); 
    } 

класс MyMethodAspect действительно используется только во время фазы компиляции, а позже она не нужна никакая дополнительная мощность Performace?

Я надеюсь, что вы можете понять, что мой вопрос, его трудно для меня, чтобы объяснить :)

благодаря

Answer 1

Давайте поговорим о реализации производительности и АОП.

АОП Framework должен быть тщательно около 3 важных вещей, чтобы быть быстрее:

• противопожарного времени (инициализация выполнения)
• перехват механик
• потребительской интеграция

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

Обычно AOP Framework, работающий во время компиляции, не имеет никакого огня, а механик перехвата аналогичен тому, как вы действительно пишете совет непосредственно в коде. Вот почему они часто эффективны.

Что касается Рамки AOP для среды исполнения, они часто не являются образцом AOP, потому что для перехвата вызовов метода им нужен прокси-сервер/фабричный шаблон. Прокси означает 2 типа накладных расходов: обертывание или приемник сообщений. В первом случае это приемлемо, а для второго это действительно стоит.

И во время компиляции и выполнение АОП имеет один и тот же вопрос для интеграции потребителей:

• бокса/распаковка
• процесса оригинального код
• , как вы можете определить ваши советы.

обосновано необходимостью определения поперечного кода.

Интеграция потребителей представляет собой реальную ошибку (проблему производительности) AOP Framework.

Время компиляции часто используется только для этого пункта. Вот почему большую часть времени они лучше с точки зрения производительности.

Я написал «обычно», потому что это верно для обычных реализаций.

В абсолютном режиме AOP Framework может работать лучше, потому что он может иметь больше информации при плетении. Сложнее (невозможно?) Реализовать эффективную среду AOP для выполнения, потому что она требовала большого количества недокументированных, известных для управления CLR.

После большого исследования я разработал новый стиль платформы AOP .NET, который может нарушить правила. NConcern .NET AOP Framework создан, чтобы быть эффективным (даже больше, чем время компиляции), предлагая эксклюзивный механик перехвата (основанный на методе swaping) и интеграцию с потребителями простым делегатом, выражением и ILGenerator, чтобы избежать бокса/распаковки и необходимости подготовки клиента. Например, большую часть времени необходимо использовать рефлексию, чтобы знать, как выполнить совет. Многие основы AOP дают метаданные в реальном режиме лечения, это означает, что у них есть накладные расходы, подготовив ее. В хорошей реализации (например, предложение NConcern) вы можете получить эту информацию до реального лечения, потому что AOP Framework предложит вам описать, как генерировать совет, вместо того, чтобы кодировать его напрямую с помощью рефлексии и бокса. Даже в базовом интерфейсе (прямое консультирование) NConcern у вас есть выбор для захвата или отсутствия метаданных.

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