Аспектно-ориентированное программирование (AOP) для С# (.Net) и их возможностей

Ответ 1

Как указывает Адам Ракис, Post # - это путь, он как можно ближе к AspectJ на платформе .NET.

Основные отличия, очевидно, в том, что AspecJ имеет поддержку языков для аспектов, в то время как Post # является компилятором post для сборщиков .NET. (таким образом, языковая интеграция)

Однако Post # может использовать точки соединения, такие как доступ к полю, try catch блоки, оба вызова и функции (то есть вызывающий и вызываемый)

• Нет даже близко, AspectJ - это язык, Post # может использовать пользовательские точки, но наиболее распространенным является использование атрибутов для украшения методов, которые должны быть pointcutted (eh..grammar?)

• Проверка

• все, кроме поддержки языка

• Проверка

• check - это почтовый компилятор

• ограниченный, ткач будет генерировать intellisense информацию и показать, какие методы были затронуты

Если вам нужен язык .NET, который поддерживает аспекты, посмотрите http://aspectsharpcomp.sourceforge.net/samples.htm

В отношении разных подходов есть несколько:

• Опубликовать компиляцию, это то, что делает Post #. Он просто управляет сборкой .NET и вставляет код аспекта.

• Реальный прокси /MarshallByRefObject. На основе удаленной инфраструктуры. Требуется, чтобы ваши классы наследовались от базового класса. Чрезвычайно плохая производительность и отсутствие "самоперехвата"

• Динамический прокси. Это то, что использовала моя старая библиотека NAspect. вы используете factory для создания подкласса типа, к которому вы хотите применить аспекты. Подкласс добавит код mixin с использованием интерфейсов и переопределяет виртуальные методы и вводит код перехватчика.

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

[edit] Я забыл добавить это в список:

5. Прокси-серверы Подобно Dynamic Proxy, но вместо того, чтобы применять код перехвата к подклассу, код перехвата добавляется в прокси-сервер, созданный с помощью среды выполнения. То есть вы получаете объект, реализующий данный интерфейс, этот объект затем делегирует каждый вызов любому из методов интерфейса сначала в код перехвата AOP, а затем он делегирует вызов реальному объекту. То есть у вас есть два объекта в игре, прокси и объект (ваш реальный объект).

Client -> Interface Proxy -> AOP interception -> Target/Subject

Это AFAIK, что делает Spring.

1) и 3) являются наиболее распространенными. У них обоих есть плюсы и минусы:

Сообщение компиляции:

Плюсы:

• Можно нарезать почти все, статическое, закрытое, личное
• Объекты все еще можно создать с помощью "нового"

Минусы:

• Невозможно применить аспекты, основанные на контексте, то есть, если тип затронут, это повлияет на все приложение.

• Точечные частные, статические, опечатанные конструкции могут привести к путанице, поскольку она нарушает основные правила OO.

Динамический прокси:

Плюсы:

• Контекстный, один тип может иметь разные аспекты, применяемые на основе контекста.

• Простота в использовании, отсутствие настроек или шагов сборки.

Минусы:

• Ограниченные точки, только элементы интерфейса и виртуальные элементы могут быть перехвачены

• должен использовать factory для создания объектов

Ответ 2

1 - Правильно

2 - PostSharp - это выдающаяся библиотека AOP для С#

3 - Я не знаю, как работает AspectJ, но с PostSharp вы просто определяете свои аспекты как атрибуты, а затем украшаете свои методы указанными атрибутами.

Вот пример аспекта, который обертывает вызов метода с помощью try catch и регистрирует любые исключения, которые вызывают:

[Serializable]
public class ErrorAspectAttribute : OnMethodBoundaryAspect {
    private bool Notify;

    public ErrorAspectAttribute(bool notifyUser = true) {
        this.Notify = notifyUser;
    }

    public override void OnException(MethodExecutionEventArgs args) {
        ErrorLoggerUtil.LogException(args.Exception);           

        if (Notify)
            MessageBox.Show("An error has occurred.  Please save blah blah blah", "Error", MessageBoxButtons.OK, MessageBoxIcon.Error);

        args.FlowBehavior = FlowBehavior.Return;
    }
}

Итак, по пунктам

1 - Я не знаю

2 - проверьте

3 - Я не знаю 4 - проверьте

5 - проверьте (уверенно)

6 - нет - не знаете, как использовать графический интерфейс для визуализации таких аспектов, как

Ответ 3

Проблема в том, что вы сравниваете разные языки и пытаетесь заставить квадратные колышки в круглые отверстия.

Для Java AspectJ возникает необходимость из-за ограничений в языке, но .NET не обязательно имеет эти ограничения, поскольку JVM не работает, но Java делает.

Например, вы можете использовать IronPython или IronRuby (в дополнение к другим) для записи очень динамичных сборок, поэтому вы можете написать DSL (язык, специфичный для домена), который позволит пользователю добавлять код, который не является XML, но изменит, как работает программа.

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

Но есть ограничения, которые могут быть трудно преодолеть, например, возможность использовать один аспект для выполнения чего-либо в каждой вызванной функции, например, с помощью cflow (http://www.eclipse.org/aspectj/doc/released/progguide/semantics-pointcuts.html), но это может быть потому, что я недостаточно думал о том, как это сделать.

Моя точка зрения заключается не в том, чтобы дать полное объяснение того, как .NET не нужен AspectJ, но чтобы показать, что есть способы получить поведение, которое вы можете ожидать, не используя AOP.

Для приложений, запущенных на JVM, вы можете использовать Groovy, Clojure, JRuby и Scala, например, для работы с ограничениями Java.

UPDATE:

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

Аспектно-ориентированное программирование (AOP) - это другая парадигма программирования для функциональности, которая пересекает классы, такие как ведение журнала. Регистрация - обычная ситуация, когда вы можете регистрировать все используемые SQL-запросы, поэтому вместо того, чтобы копировать код с места на место, вы помещаете его в одно место и включаете в него везде, где вы указываете, поэтому, если вы решите позже чтобы изменить место регистрации, вы меняете его в одном месте.

Но с AspectJ есть больше вариантов. Например, вы продаете программу, в которой хранятся пароли. Компания A использует IDEA, компания B использует AES. Чтобы адаптироваться, вы меняете код, который используется во время выполнения, поэтому вам не нужно рисковать перекомпилировать код и вводить новые ошибки, и он изменяется, так что всякий раз, когда кто-то звонит getPassword(), новый код используется для его дешифрования.

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

Но, используя другие языки, которые находятся на .NET и JVM, вы можете сделать все это с той же модулярностью, тщательно подобрав, какой язык использовать. Например, в Java вы можете получить доступ к классам, написанным в Groovy или Scala, чтобы вы могли получить большую гибкость с этими языками и все еще иметь основное приложение на Java.

В С# вы можете использовать F #, IronPython или IronRuby, например, чтобы получить эту функциональность, или, в некоторых случаях, вы можете использовать С#.

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

Для получения дополнительной информации о АОП у IBM были некоторые невероятные статьи об использовании ее, с их серией AOP @Work: http://www.ibm.com/developerworks/views/java/[email protected]:

Для некоторых мыслей о AOP на .NET вы можете прочитать код AOG против Runtime Proxy AOP , http://rogeralsing.com/2008/01/08/code-mangling-aop-vs-runtime-proxy-aop/