Яка найкраща реалізація AOP у .Net? [зачинено]

83

У C #, VB.net багато реалізації AOP. це деякі з реалізацій AOP:

Яка найкраща реалізація AOP у .Net? Що я повинен використовувати?

.net  aop 
— ecleel
джерело
4
Було б корисно, якщо б ви надали посилання на всі AOP, щоб заощадити читачеві трохи часу з Google. Я сподіваюся, що це запитання / відповіді стануть чудовим підсумком різних варіантів AOP у .NET
— Ян Рінгроуз
10
52 людини проголосували, що це конструктивне питання. 5 проголосували, що це не конструктивно. Хто вирішив? Принаймні модератору слід змінити або переформулювати питання, але їм краще врахувати думку більшості людей.
— Ревізований
2
@Revious Повністю згоден!
— Legends
1
Дивовижно, що ТАК і люди проти таких питань, як цей, заперечують. Таке корисне питання та технологія для обговорення та сприяння спільноті стає просто проголосованим і закритим, але купа старомодних людей у ​​стилі 80-х років, які застрягли в минулому. ТАК, світ змінився. Цілком зрозуміло, що ви хочете допомогти відповісти на конкретні запитання, але принаймні надайте посилання у своєму "закритому" тезі, де розміщувати такі запитання. Це дуже допомогло б і уникнуло подібної дурості.
— піксель

Відповіді:

45

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

Якщо динамічне перехоплення не може задовольнити ваші потреби (плетіння герметичного класу, перехоплення невіртуального дзвінка тощо), то ви, звичайно, хочете статичне плетіння. PostSharp є посиланням у цьому домені.

Зверніть увагу, що він також існує Linfu , який може використовуватися для використання обох моди AOP.

— Ромен Вердьє
джерело
3
+1 для цього, якщо ви хочете виконати виконання AOP. +1 на PostSharp, якщо ви хочете час після компіляції AOP
— Кшиштоф Козміч
Будь-яке оновлення щодо цієї відповіді? Або це все ще діє? Мені було особливо цікаво, як Spring.Aop порівнюється із Castle і PostSharp
— Evren Kuzucuoglu
1
на жаль, PostSharp є комерційним продуктом
— піксель
Postsharp - комерційний продукт, не безкоштовний. Будь ласка, порадьте що-небудь ще щодо статичного ткацтва.
— Шивам Сачан
@ShivamSachan Тільки тому, що щось безкоштовне, це не робить добре. Більшість безкоштовних AOP у .net загинуло з останніми оновленнями 2-5 років тому, PostSharp все ще найкращий у своєму класі.
— Offler
15

"Найкраще" - це суб'єктивно.

Спочатку складіть список потрібних вам функцій, вашої архітектури тощо. Потім шукайте варіанти, які роблять те, що вам потрібно, не вносячи зайвої складності. Наприклад, декілька орієнтовані на інтерфейс: чи орієнтований ваш код на даний момент на інтерфейс? Якщо ні, то PostSharp може бути кращим вибором (будучи вписаним в оригінальні класи). Але, звичайно, PostSharp не можна налаштувати під час ... коней на курси.

— Марк Гравелл
джерело
Ви могли б переформулювати сказане таким чином: "Найкраще - це суб'єктивно, я складу список" за "і" проти "для деяких з цього фреймворку".
— Огляд
11

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

Ось декілька вказівок:

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

Коли у вас є правильні абстракції, додавання нових наскрізних проблем до системи - це лише питання написання нового класу декораторів та обгортання його навколо правильних реалізацій. Якщо абстракції є загальними, ви можете обернути один декоратор навколо великої групи класів (саме про це йдеться в AOP).

Хоча такі методи, як динамічні проксі-сервери та переплетення коду, можуть полегшити роботу з погано розробленим додатком, справді немає альтернативи хорошому дизайну. Рано чи пізно ви обпечетеся. Це не означає, що динамічне генерування проксі-сервера та переплетення коду не слід використовувати. Але без належного дизайну додатків навіть ці методи будуть просто незначно корисними.

— Стівен
джерело
AOP - це наступний рівень абстракції. Насправді це обмеження спадщини та складу, що призводить до AOP. Ви бачили блок винятків Entlib? Aspect набагато чистіший, ніж виклик цього проклятого блоку для кожного окремого дзвінка в базу даних, просто щоб спробувати-catch-log-throw.
— Sleeper Smith
2
Якщо ви обертаєте кожен виклик до бази даних блоком винятків, ви все одно робите це неправильно. Це повертається до гарного дизайну. Завжди.
— Стівен
Тож замість того, щоб ловити винятки db, який правильний шлях?
— OutOFTouch
2
@OutOFTouch: Погляньте на відповідь на це питання SO .
— Стівен
2
@SleeperSmith: хоча я не впевнений, що означає "AOP - це наступний рівень абстракції", я вважаю, що ти не можеш тримати великі системи в обслуговуванні без використання AOP. Я вірю у застосування AOP. Однак AOP є парадигмою; не інструмент. Я погоджуюся з обмеженням спадкування, але це не обмеження складу, що призводить до AOP. Відсутність належного дизайну призводить до використання засобів переплетення коду та інструментів динамічного проксі. Я застосовую наскрізні проблеми, використовуючи декоратори. Це мій найкращий спосіб застосування AOP.
— Стівен
5

Я не знаю про найкраще, є багато рамок і не вистачає годин на день, щоб спробувати їх усі.

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

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

Для нових проектів зараз я б, мабуть, використовував Castle Windsor, але це здебільшого тому, що я також хотів би використовувати IoC. Якби мені довелося швидко впровадити AOP в існуючу базу коду, я б використовував PostSharp.

— Мендельт
джерело
Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.