Когда в последний раз я консультировал одну компанию, мы обсуждали внутренний SOA фреймворк, который должен взаимодействовать с базами данных предприятия. Этот фреймворк был SOA только разве что по названию, полностью доморощенный, и что самое грустное, он был «любимым проектом» начальника отдела ИТ. Он был не безопасным и построен на сомнительных технологиях и решениях. В общем он был сделан для решения некоторой проблемы, которой либо не существует, либо она не могла была разрешима боле простыми средствами. Моя команда была крайне разочарована структурой этого фреймворка. Но, в качестве консультанта, очень часто приходится сначала продумать пути решения проблемы, нельзя порсто сказать заказчику что его продукт «плохой», необходимо сначала построить его доверие к себе, и только потом решать более серъезные проблемы. Так или иначе такой процесс может занять годы, и все зависит от фирмы, в которой будут происходить такого рода изменения. Тогда я и задумался над тем чтобы начать использовать аспектно-ориентированный фреймворк чтобы решить эту проблему

Кусок кода, представленный ниже, вы наверняка писали не один раз. А что более вероятно – десятки раз. Обычно это пишется, когда необходимо использовать некий репозиторий, который будет предоставлять данные для вашего приложения. Если у вас мало времени, и вы торопитесь, это отличный способ получить что-либо таким образом, что это будет загружено в память только тогда, когда это вам понадобится, но не раньше (например, операция сохранения повлекла за собой обращение к подсистеме сериализации, однако до этого она не была нужна). И ведь на самом деле получается, что этот кусок кода с одной стороны одинаков, а с другой – его приходится писать не один раз.
Как правило, я и многие программисты, предпочитаем использовать в данном месте IoC контейнер, чтобы решать задачи такого рода. Однако это не всегда так просто сделать, особенно когда я программирую в рамках отсутствия Dependency Injection в библиотеке, которую я использую (WinForms, WebForms, …). Давайте разберемся, почему решая эту задачу без использования PostSharp, вы потратите гораздо больше времени и проделаете больше работы.

И снова здравствуйте! В прошлый раз при обсуждении АОП, мы с вами говорили о решении задач кэширования. Сегодня мы поговорим о не менее часто встречающейся задаче – задаче логгирования и аудита. Нам часто приходится сталкиваться с такими ситуациями, как, например, анализ чужого кода. Представьте себе, что вам дали задачу интеграции с библиотекой стороннего производителя. Основной инструментарий чуть ли не каждого разработчика — .net reflector, ILSpy, dotPeek дают отличное представление о коде программы. О ее алгоритмах, структуре, возможных местах ошибок. И покрывают большой процент вопросов к программному продукту. Однако так происходит до тех пор, пока вы не начинаете ее активно использовать. Тут могут возникнуть как проблемы с производительностью, так и с непонятными «багами» внутри стороннего продукта, которые, если не иметь дизассемблера с функцией отладчика, не так-то просто найти. Или, например, вам необходимо просто следить за значениями переменных, не останавливая продукт в точках останова, real-time. Такие места часто необходимо срочно и быстро исправлять. А как при исправлении этого кода не написать программу, которая потом будет в топе сайта govnokod.ru? О таких ситуациях мы сейчас и поговорим.

Иногда попадаются такие ситуации, в которых нет никакой возможности ускорить работу некоторой операции. Она может зависеть от какого-то сервиса, который располагается на внешнем web сервере, или это может быть операция, которая дает высокую нагрузку на процессор. Или же это могут быть быстрые операции, однако, их параллельная работа может высосать из вашего компьютера все ресурсы производительности. Существует огромное количество причин чтобы использовать кэширование. Следует отметить, что PostSharp, изначально не предоставляет решений для вас какого-либо фреймворка кэширования, просто он позволяет сделать эту задачу на порядки быстрее, без каких-либо занудных действий, типа расстановки кода, отвечающего за кэширование по всему исходному тексту программы. Он позволяет решить эту задачу элегантно, вынося задачи в классы и позволяя их повторно использовать.

В моем разговоре с Андресом Хейлсбергом о страхах, неуверенности и сомнений относительно Аспектно-Ориентированного программирования я упомянул про общую путаницу и непонимание что АОП и DI – это конкурирующие концепции. В этой статье я попробую объяснить вам обо всех различиях и сходствах в этих двух подходах.Недавно я прекрасно провел время за чтением статьи Дино Эспосито: «Аспектно-ориентированное программирование, interception и unity 2.0», в декабрьском номере MSDN Magazine. Это великолепная статья и я настоятельно советую любому разработчику, вовлеченному в .NET разработку прочитать ее полностью. Как и многие DI фреймворки, и некоторые основные фреймворки (WCF, ASP.NET MVC), Unity предлагает похожую на АОП возможность: interceptors.