Собственно поэтому я и юзаю 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.
Насколько я помню, для четвертого фреймворка постшарп уже только платный, по крайней мере для коммерческих приложений. Да и время сборки он заметно увеличивает. То есть инструмент интересный, но как и все — не без ограничений
Для профилирования обычно больше походит GetProcessTimes, которая возвращает время работы именно конкретного процесса, а не системы вообще, то есть на время не будет оказывать загруженность ядра другими приложениями. + Можно посмотреть отдельно время работы в пользовательском режиме и режиме ядра.
А вообще, по-моему, профилировать все таки удобнее и проще специальным ПО. Особенно когда нужно найти не время работы конкретной функции, а узкое место в определенной операции. Тут тебе и стек выховов и количество вызовоз каждой функции и время выполнения вплоть до построчного. В общем, рекомендую
Это еще не конец:) Будет еще небольшая часть про Live Services. Если сразу много информации, то рекомендую читать первую часть, там взгляд сверху, без деталей.
Когда переводил, думал о варианте «прослойка», но он какой-то слишком общий на мой взгляд. С другой стороны есть программерское понятие «фабрики» из паттерна «фабрика» как штуки, отвечающей за создание экземпляров и управление их жизнью. Если заменить экземпляры класса на виртуальные машины, то получается неплохая аналогия. Поэтому выбрал фабрику.
Пока это только CTP и все бесплатно. В дальнейшем говорят, что оплата будет формироваться из объема потребленных услуг — за гектары хранилища, время работы процессоров, канал, количество транзакций и т.п. То есть пока пользователей мало — мало платим, как только приложение «пошло», то плата увеличится.
1. Нельзя просто создавать объекты через конструктор, так как тогда они не будут обернуты в динамические проксики с аспектами. Но это совсем не проблема, если все создается через IoC.
2. Если через Introduction Advice (в терминах Spring.Aop) добавлять к классу реализацию какого-то интерфейса, например INotifyPropertyChanged, то внутри самого класса нельзя сказать (INotifyPropertyChanged)this, так как понятно, что this — это ссылка на сам объект, а не его проксик с аспектами, и сам объект это интерфейс не реализует. Пару раз нарывался.
3. Забыл уже конкретику, но была проблема с биндингами WPF на объект, обернутый в проксик с аспектами, связанный с особенностью реализации Weak Events в биндингах WPF. Проблема решаемая, но очень неочевидная и в свое время пришлось ковырять исходники .Net, чтобы с ней разобраться.
У АОП через проксики есть и плюсы — например, можно на лету делать подмену таргета (объекта, который оборачивается в проксик). Через это, например, делается ленивая загрузка свойств в NHibernate, при этом исходный объекто остается POCO.
А вообще, по-моему, профилировать все таки удобнее и проще специальным ПО. Особенно когда нужно найти не время работы конкретной функции, а узкое место в определенной операции. Тут тебе и стек выховов и количество вызовоз каждой функции и время выполнения вплоть до построчного. В общем, рекомендую