Comments 24
Глядя на все эти Mono-cecil чудеса всегда хочется задать вопрос: как потом дебажить?
Интересно! А если методов много, есть ли способ делать трассировку всех вызываемых методов из определенной сборки?
инструмент очень полезный. но думаю было б лучше если б рассмотрели на примере поживее — например разграничение прав доступа или управление транзакциями к базе.
Вот топик — сборник полезных аспектов.
UFO just landed and posted this here
Насколько я помню, для четвертого фреймворка постшарп уже только платный, по крайней мере для коммерческих приложений. Да и время сборки он заметно увеличивает. То есть инструмент интересный, но как и все — не без ограничений
Почти во всех популярных IoC/DI — фреймворках есть поддержка АОП. Например, в Spring.net и Castle.
Время сборки увеличено не будет, только время первого старта приложения. Причем, никакие левые атрибуты вешать не придется, код будет чистым poco. А тулзы типа PostSharp — это для энтузиастов.
Время сборки увеличено не будет, только время первого старта приложения. Причем, никакие левые атрибуты вешать не придется, код будет чистым poco. А тулзы типа PostSharp — это для энтузиастов.
Собственно поэтому я и юзаю Spring.Aop из Spring.Net, но и у него есть тоже пара недостатков в сравнении с PostSharp, связанные как раз с тем, что там аспекты навешиваются не в CompileTime, а в RunTime через генерацию динамических проксиков:
1. Нельзя просто создавать объекты через конструктор, так как тогда они не будут обернуты в динамические проксики с аспектами. Но это совсем не проблема, если все создается через IoC.
2. Если через Introduction Advice (в терминах Spring.Aop) добавлять к классу реализацию какого-то интерфейса, например INotifyPropertyChanged, то внутри самого класса нельзя сказать (INotifyPropertyChanged)this, так как понятно, что this — это ссылка на сам объект, а не его проксик с аспектами, и сам объект это интерфейс не реализует. Пару раз нарывался.
3. Забыл уже конкретику, но была проблема с биндингами WPF на объект, обернутый в проксик с аспектами, связанный с особенностью реализации Weak Events в биндингах WPF. Проблема решаемая, но очень неочевидная и в свое время пришлось ковырять исходники .Net, чтобы с ней разобраться.
У АОП через проксики есть и плюсы — например, можно на лету делать подмену таргета (объекта, который оборачивается в проксик). Через это, например, делается ленивая загрузка свойств в NHibernate, при этом исходный объекто остается POCO.
1. Нельзя просто создавать объекты через конструктор, так как тогда они не будут обернуты в динамические проксики с аспектами. Но это совсем не проблема, если все создается через IoC.
2. Если через Introduction Advice (в терминах Spring.Aop) добавлять к классу реализацию какого-то интерфейса, например INotifyPropertyChanged, то внутри самого класса нельзя сказать (INotifyPropertyChanged)this, так как понятно, что this — это ссылка на сам объект, а не его проксик с аспектами, и сам объект это интерфейс не реализует. Пару раз нарывался.
3. Забыл уже конкретику, но была проблема с биндингами WPF на объект, обернутый в проксик с аспектами, связанный с особенностью реализации Weak Events в биндингах WPF. Проблема решаемая, но очень неочевидная и в свое время пришлось ковырять исходники .Net, чтобы с ней разобраться.
У АОП через проксики есть и плюсы — например, можно на лету делать подмену таргета (объекта, который оборачивается в проксик). Через это, например, делается ленивая загрузка свойств в NHibernate, при этом исходный объекто остается POCO.
А вообще, хорошую инфу про разные способы реализации АОП в .Net, их плюсы и минусы, видел тут — http://ayende.com/Blog/archive/2007/07/02/7-Approaches-for-AOP-in-.Net.aspx
есть способ поставить, например, Trace на класс, но чтобы он «вызывался» на все методы этого класса?
мне кажется, что логирование это динамическая штука, т.е. в зависимости от контекста ее нужно включать или выключать. а PostSharp вынуждает прямо в исходниках низкоуровневых классов вставлять атрибуты?
а если не хочется менять исходники или их нет?
не является ли dynamic proxy более подходящим инструментом для данного типа задач? ведь он требует менять только контекст, а не низкоуровневые классы?
а если не хочется менять исходники или их нет?
не является ли dynamic proxy более подходящим инструментом для данного типа задач? ведь он требует менять только контекст, а не низкоуровневые классы?
Ну если нужно включить логи для всех классов сборки, можно указать атрибут в AssemblyInfo.cs (т.е. нет необходимости вписывать это в каждый класс).
Согласен, для случая, когда нет исходников больше подходит dynamic proxy. Но логи — это лишь одна из задач, которую можно решить при помощи АОП.
Согласен, для случая, когда нет исходников больше подходит dynamic proxy. Но логи — это лишь одна из задач, которую можно решить при помощи АОП.
Используйте аттрибут Conditional для аттрибута (забавно звучит :) )
Sign up to leave a comment.
Аспектно-ориентированное программирование. PostSharp