Какая лучшая реализация для АОП в .Net? [закрыто]

83

В C #, VB.net много реализаций АОП. это некоторые из реализаций АОП:

Какая лучшая реализация для АОП в .Net? Что мне следует использовать?

.net  aop 
— Ecleel
источник
4
Было бы полезно, если бы вы предоставили ссылки на все АОП, чтобы сэкономить читателю время с Google. Я надеюсь, что этот вопрос / ответы станут отличным обобщением различных параметров АОП в .NET
— Ян Рингроуз,
10
Проголосовало 52 человека, это конструктивный вопрос. 5 проголосовали неконструктивно. Кто решил? По крайней мере, модератор должен изменить или переформулировать вопрос, но им лучше учитывать мнение большинства людей.
— Revious
2
@Revious Полностью согласен!
— Legends
1
Удивительно, что SO и люди голосуют против таких вопросов, как OT. Такой полезный вопрос и технология для обсуждения и помощи сообществу просто отвергаются и закрываются, но кучка старомодных людей в стиле 80-х застряла в прошлом. ТАК, мир изменился. Совершенно понятно, что вы хотите помочь в ответах на конкретные вопросы, но, по крайней мере, укажите ссылку в своем «закрытом» теге, где можно разместить такие вопросы. Это очень поможет и поможет избежать такой глупости.
— pixel

Ответы:

45

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

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

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

— Ромен Вердье
источник
3
+1 к этому, если вы хотите выполнить АОП во время выполнения. +1 на PostSharp, если вы хотите AOP после компиляции
— Кшиштоф Козьмич
Есть обновления по этому ответу? Или это еще в силе? Мне было особенно интересно, как Spring.Aop сравнивается с Castle и PostSharp
— Эврен Кузуджуоглу
1
к сожалению, PostSharp - это коммерческий продукт
— pixel
Postharp - это коммерческий продукт, а не бесплатный. Пожалуйста, посоветуйте что-нибудь еще для статического плетения.
— Шивам Сачан
@ShivamSachan Только потому, что что-то бесплатное, плохо. Большинство бесплатных АОП в .net умерло с последними обновлениями 2-5 лет назад, PostSharp по-прежнему остается лучшим в своем классе.
— Offler
15

«Лучший» - это субъективно.

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

— Марк Гравелл
источник
Вы могли бы переформулировать сказанное следующим образом: «Лучшее субъективно, я составлю список за и против для некоторых из этого фреймворка».
— Revious
11

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

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

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

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

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

— Стивен
источник
АОП - это следующий уровень абстракции. Фактически, это ограничение наследования и композиции, которые приводят к АОП. Вы видели блок исключений Entlib? Аспект намного чище, чем вызов этого проклятого блока для каждого отдельного вызова в базе данных, просто чтобы попробовать-поймать-журнал-бросить.
— Sleeper Smith
2
Если вы завершаете каждый вызов своей базы данных блоком исключения, вы все равно делаете это неправильно. Возвращается к хорошему дизайну. Всегда.
— Стивен
Итак, вместо того, чтобы ловить исключения db, что является правильным?
— OutOFTouch 04
2
@OutOFTouch: Взгляните на ответ на этот ТАК вопрос .
— Стивен
2
@SleeperSmith: хотя я не уверен, что означает «АОП - это следующий уровень абстракции», я действительно думаю, что невозможно поддерживать большие системы в обслуживании без использования АОП. Я верю в применение АОП. Однако АОП - это парадигма; не инструмент. Я согласен с ограничением наследования, но это не ограничение композиции, которое приводит к АОП. Отсутствие правильного дизайна приводит к использованию инструментов переплетения кода и динамического прокси. Я применяю сквозные задачи с помощью декораторов. Это мой предпочтительный способ применения АОП.
— Стивен
5

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

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

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

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

— Мендельт
источник
Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.