2016-03-03 5 views
0

Начну с того, что я новичок в перехвате.Есть ли способ использовать перехват, но оставаться независимым от рамки AOP за

Я хочу заменить некоторые существующие реализации моего проекта путем привлечения перехвата в игру, но я заметил, что он на самом деле приносит мне быть очень тесно связан с АОПОМ позади (либо Castle.DynamicProxy, Unity.Interception, LinFu.AOP, тем же историей). Что делать, если мне нужно переключаться между ними? (есть много причин, почему).

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

Простой пример, показывающий, «до» перехватчик с замком DynamicProxy:

public abstract class BeforeInterceptor : IInterceptor 
{ 
    void IInterceptor.Intercept(IInvocation invocation) 
    { 
     Before(invocation); 
     invocation.Proceed(); 
    } 

    protected abstract void Before(IInvocation invocation); 
} 

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

Каковы ваши предложения и рекомендации. Возможно, я вижу это под неправильным углом.

PS: При использовании таких библиотек для DI это не так, нет такой жесткой связи.

+1

Если это всего лишь один или два класса, то самым простым способом было бы вручную раскрутить ваши собственные Декораторы. Если у вас есть нечто большее, вы можете создать декораторы с использованием Roslyn/Code gen, возможно, с шаблонами T4 и/или настраиваемыми действиями в вашей сборке. Если вам нужен код потребления, чтобы не «знать» о типе декоратора, то могут помочь пользовательские дескрипторы типов. –

+0

Спасибо за рекомендации Тоби! – Learner

ответ

0

Наличие перехватчиков, связанных с реализацией DI, не так уж плохо. Причина, по которой код находится в перехватчике, заключается в том, что он не принадлежит классу, метод которого перехвачен. Обычно это поведение, которое вы не хотите сочетать с вашим классом, и оно не входит в компетенцию этого класса. Поэтому, если вы связываете свои перехватчики вместо своих «основных» классов, то это достойный компромисс. Это держит эти классы несвязанными.

Кроме того, настройка вашего контейнера DI не обязательно должна быть в том же проекте, что и связанные классы. Если бы вы захотели, у вас мог бы быть установщик Windsor для подключения ваших классов и перехватчиков для Windsor, а другой для единства. Это дублирование, но тот факт, что вы можете иметь оба, означает, что вы не связаны с техникой.

И код в ваших перехватчиках обычно довольно минимален. Если он делает что-то слишком сложное, то, возможно, оно не принадлежит.

+0

Вы сказали, что код перехватчика должен быть минимальным, в общем ... На самом деле я думал, что могу использовать перехватчики при наличии дополнительных проверок для добавления в определенных условиях только пары BL-методов внутри одного объекта BL (например, на основе лицензии и т. Д.). .. Я не хочу создавать перехватчики на уровне BL, которые жестко привязаны к любой инфраструктуре AOP/DI. – Learner

+0

Моя забота становится слишком зависимой от реализации DI. Я бы постарался поставить бизнес-логику в перехватчик. Я использую их для проблем, которые не связаны с этой логикой (и поэтому не относится к этим классам.) В некоторых случаях я, вероятно, уже связан с Виндзором и должен пересмотреть некоторые детали. –

Смежные вопросы