Какая наилучшая реализация для АОП в .Net?

Ответ 1

Я думаю, что Castle Dynamic Proxy является решением, если динамический перехват может удовлетворить ваши потребности. Эта структура используется внутренне множеством других инфраструктур, которые хотят предлагать возможности AOP. Как правило, большинство существующих контейнеров IoC теперь предоставляют некоторые механизмы динамического перехвата (Spring.NET, Castle Windsor, StructureMap и т.д.). Если вы уже работаете с контейнером IoC, возможно, было бы проще посмотреть, что он предлагает.

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

Обратите внимание, что он также существует Linfu, который может использоваться для использования обе стилей AOP.

Ответ 2

"Лучшее" субъективно.

Сначала создайте список необходимых функций, свою архитектуру и т.д. Затем найдите варианты, которые делают то, что вам нужно, не вводя излишнюю сложность. Например, некоторые из них ориентированы на интерфейс: ваш код в настоящее время ориентирован на интерфейс? Если нет, PostSharp может быть лучшим выбором (сотканный в исходные классы). Но, конечно, PostSharp не может быть настроен во время выполнения... лошадей для курсов.

Ответ 3

Лучший способ сделать аспектно-ориентированное программирование в .NET - это использование хорошо известных методов проектирования. Например, применяя принципы SOLID, вы можете достичь гибкости и модульности, которые необходимы для того, чтобы добавить многоречивые проблемы. Если у вас есть право на дизайн, вы даже сможете применять большинство сквозных задач без каких-либо фреймворков. Ошибочно думать, что ООП не подходит для выполнения АОП.

Вот несколько указателей:

• Не зависит от конкретных экземпляров, но зависит от абстракций.
• Не смешивайте сквозные проблемы и бизнес-логику в одном классе.
• Добавление сквозных проблем путем объединения классов с бизнес-логикой в ​​классы, которые реализуют эти проблемы (декораторы).
• Найдите общие артефакты в своем дизайне и смоделируйте их одинаково, предпочтительно используя те же типы абстракций. Посмотрите этот и этот, например.

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

Хотя такие методы, как динамические прокси и кодовое переплетение, могут облегчить работу с плохо разработанным приложением, для хорошего дизайна действительно нет альтернативы. Рано или поздно вас сожгут. Это не означает, что динамическое создание прокси и кодовое ткачество не должны использоваться. Но без надлежащего дизайна приложения даже эти методы будут незначительно полезны.

Ответ 4

Я не знаю о лучшем, есть много фреймворков и недостаточно часов в день, чтобы попробовать их всех.

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

Я также просмотрел AOP с Castle Windsor и Spring.Net, подход отличается (время выполнения и время компиляции). Смешивание AOP и IoC, кажется, имеет смысл. Если вы не используете одну из этих фреймворков, еще много работы, чтобы начать работу, но не позволяйте этому останавливать вас.

Для новых проектов теперь я бы, вероятно, использовал Castle Windsor, но в основном потому, что я тоже хотел бы использовать IoC. Если бы мне пришлось быстро внедрить АОП в существующую базу кода, я бы использовал PostSharp.

Ответ 5

Там также введена политика и Unity Interception от Microsoft.