AOP можно использовать для обмена данными между различными запущенными потоками в процессе приложения?

Question

Обновить:Мне не совсем ясно, в каком контексте следует использовать AOP?Поскольку мы можем использовать AOP для ведения журнала, обеспечения безопасности (аутентификации), пожалуйста, предложите несколько других сценариев, в которых мы могли бы воспользоваться преимуществами AOP.

Может ли AOP использоваться для обмена данными между различными запущенными потоками в процессе приложения?

Answer 1

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

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

Ресурсы

В настоящее время AOP не встроен в C #, но там следующие фреймворки могут создавать AOP:

• Аспект
• НАспект
• Постшарповый
• LOOM.Net
• Spring.Net

AOP для данных потока

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

• [ThreadStaticAttribute] Добавьте этот атрибут к полям, чтобы указать среде выполнения .NET, что следующее поле будет уникальным для нескольких потоков

• Синхронизация (наиболее распространенный метод) Использование Mutexes, Semaphores, ReaderWriter замки и EventWaitHandles для синхронизации доступа к локальным или глобальным данным из нескольких потоков.В C # lock оператор - это синтаксический сахар для Monitor класс, который может быть использован для "блокировки" доступа к объекту из одного потока.

Answer 2

Мне нравится думать о AOP как об умном закулисном генерировании кода (время компиляции) / выполнении (время выполнения), так что вы можете делать практически все что угодно. Он имеет все преимущества (и даже больше) традиционной генерации кода без недостатков (например, ремонтопригодность).