Автореферат (1148250), страница 3
Текст из файла (страница 3)
Показана необходимость и осуществлена интеграция Aspect.NET со средой разработки Microsoft Visual Studio через события пред- и пост-компиляции. Такжебыла описана реализация в Aspect.NET возможности удаленной отладки результирующих приложений на облачных серверах. Далее в главе проанали9зирована типичная сквозная функциональность облачных веб-приложений набазе ASP.NET MVC и реализовано расширение функциональных возможностей Aspect.NET для поддержки ее выделения в аспекты, а именно:1) автоматическое слияние конфигурационных XML-файлов аспектного и целевых проектов при компиляции, что позволило сократитьколичество настроек в целевом проекте до минимального количества,необходимого для бизнес-логики;2) перехват целевых методов обратного вызова, которые вызываются платформой с помощью автоматической замены целевого класса егоаспектным наследником.В последнем случае потребовалась реализация в Aspect.NET специального пользовательского атрибута [ReplaceBaseClass], предписывающего компоновщику заменить целевой класс своим аспектным наследником.
Например, аспект, замещающий метод обратного вызова LogButton_Click в классевеб-страницы Default (который теперь содержит только бизнес-логику), может выглядеть как на листинге 1:[ReplaceBaseClass] public class AspectClass : Default { protected void LogButton_Click(object sender, EventArgs e) { //Совершаем действия перед вызовом целевого метода… base.LogButton_Click(sender, e); //Совершаем действия после вызова целевого метода } }Листинг 1: Аспектный класс-наследник для обработки щелчка мышьюВ четвертой главе ставилась задача создания универсальных аспектов,которые могут быть применены к различным облачным приложениям.
Аспекты могут быть описаны как в программном коде, так и в файле конфигурации (обычно в web.config). Оба этих способа задействуются в аспекте, который перенаправляет отладочную информацию в облачное хранилищеWAD: действия аспекта запускают диагностический монитор, а файл конфигурации аспекта регистрирует этот диагностический монитор в качестве приемника отладочной информации.Далее был представлен аспект, который повышает надежность любогоцелевого метода путем определения стратегии реакции на его исключения.В качестве примера (листинг 2) взята стратегия “Предохранитель” (CircuitBreaker):10class SimpleCircuitBreakerAspect : Aspect { static DateTime ? errorTime = null; //Таймаут, в течение которого предохранитеь будет закрыт static readonly int resetTimeoutInMilliseconds = 1000; [AspectAction("%instead %call *UnreliableService.GetContent")] public static string GetContentSafe() { //Если errorTime.HasValue, то предохранитель закрыт. if (errorTime.HasValue) //Если еще не истек таймаут с момента последнего неуспешного вызова if ((DateTime.Now ‐ errorTime.Value).TotalMilliseconds < resetTimeoutInMilliseconds) return GetAnotherContent(); // Вызывается запасной метод try { //Проверяем доступность целевого метода string result = (TargetMemberInfo as MethodInfo).Invoke(TargetObject, null); //Исключения не было, открываем предохранитель errorTime = null; return result; } catch (Exception) { //Закрываем предохранитель, запомнив время сбоя. errorTime = DateTime.Now; //Вызываем запасной метод return GetAnotherContent(); } } //Запасной вариант действий при сбое private static string GetAnotherContent() { return "Service is busy"; } }Листинг 2: Аспект для реализации паттерна “Предохранитель”Следующим был описан аспект, повышающий производительность целевого метода, через кэширование его результата средствами Windows AzureCaching.Наконец, приведена XML-конфигурация аспекта, которая позволяет менять способ хранения веб-сессии.
В рамках библиотеки AzureLibrary реализованы вышеописанные аспекты, что позволяет расширить этой же функциональностью другие веб-приложения.В пятой главе сформулированы приемы для выделения из целевыхклассов веб-приложений зависимостей от служб Microsoft Azure в аспекты.На примере службы кэширования демонстрируется “очищение” целевогобизнес-класса от вторичной функции кэширования и выделения еев %instead-действие аспекта, пригодного для повторного использования.В том случае, когда требуется подвергнуть АОП-рефакторингу метод (callback), вызываемый инфраструктурой Microsoft Azure, рекомендуется создатьдля него аспектный производный класс через атрибут [ReplaceBaseClass].Однако это не поможет в случае, когда требуется переопределить целевой метод рабочей или веб-роли, так как Microsoft Azure требует для роли толькопрямого наследования от класса RoleEntryPoint.
В этом случае целиком заме11нить его не получится, но можно расширить его поведение, привязав %beforeили %after-действие аспекта к вызову методов RoleEntryPoint.В ряде случаев сквозная функциональность требует отдельной панелинастройки от пользователя в .aspx-разметке ASP.NET MVC приложения. Тогда в рамках АОП-рефакторинга она выделяется в отдельный аспект, содержащий .ascx-компонент представления указанной панели, связаннуюс моделью данных для сквозной функциональности, и класс целевого контроллера расширяется аспектным замещающим наследником для поддержкинового .ascx-компонента.
Такой прием повышает повторную используемостьсквозной функциональности, однако бывают случаи, когда в представленииесть лишь несколько разнородных полей, управляющих службой, которые неимеет смысла или затруднительно объединять в одну панель. В этом случаеоптимальным будет решение выделить в классе страницы для них пустыеprivate-свойства, а реализацию определить в аспекте с помощью %insteadдействий.Все приведенные приемы АОП-рефакторинга позволяют переложитьобязанность работать со службами Microsoft Azure с целевого классана аспект, что фокусирует его на реализации исключительно бизнестребований. Конкретные преимущества демонстрируются повышениему целевых классов комбинированной метрики качества кода MaintainabilityIndex.
В заключение приведены примеры АОП-рефакторингов промышленных систем N2CMS и Orchard CMS и, также с помощью метрикиMaintainability Index, продемонстрировано улучшение качества их исходногокода.В шестой главе представлены основные принципы бесшовного расширения функциональности облачных веб-приложений с помощью Aspect.NETи сторонних библиотек.
В результате разрывается зависимость между целевым приложением, применяемой АОП-системой и сторонней библиотекой,что позволяет заменить их в любой момент прозрачно для целевого приложения. При этом сторонняя библиотека предоставляет классы для реализациисквозной функциональности, а Aspect.NET средства для их интеграции в целевое приложение. В качестве сторонней библиотеки выбрана MicrosoftEnterprise Library Integration Pack, функциональные блоки которой позволилибесшовно внедрить в веб-приложение сквозную функциональность протоколирования, автоматического масштабирования нагрузки и динамически конфигурируемой стратегии реакции на исключения. На листинге 3 представлено решение задачи вынесения в аспект протоколирования с помощью аспектного наследника:12//Проект с замещающим аспектным наследником [AspectDotNet.ReplaceBaseClass] public class AspectClass : Default { protected void LogButton_Click(object sender, EventArgs e) { Microsoft.Practices.EnterpriseLibrary.Logging. Logger.Write("Message from the Logging Application Block"); base.LogButton_Click(sender, e); } } //Исходный проект, после отделения зависимости от Logging Application Block public partial class Default : System.Web.UI.Page{ protected void LogButton_Click(object sender, EventArgs e) {} } Листинг 3: Протоколирование, вынесеное в аспектДля бесшовной интеграции сквозной функциональности в ряде случаевдостаточно основных средств Aspect.NET, а именно замещающего аспектного наследника и %instead, %after, %before-действий.
Однако, иногда замещающий аспектный наследник должен вызывать закрытый метод своего базового класса и, в этом случае, необходимо использовать рефлексию .NET. Втом случае, когда происходит несколько таких вызовов, то оптимальным будет сохранение ссылок на метаданные соответствующего закрытого метода вполях аспектного наследника и их инициализация в конструкторе.В том случае, когда замещающий аспектный наследник должен иметьконструкторы отличные от базового класса (например, для инициализациизависимостей от Microsoft Enterprise Library), тогда необходимо %insteadдействиями заменить и вызовы всех его конструкторов в целевом коде.В результате для бесшовной интеграции Microsoft Enterprise Libraryв целевое веб-приложение достаточно создать новый проект с аспектом, установить Microsoft Enterprise Library в него с помощью менеджера расширений Nuget, написать код аспекта и в свойствах проекта задать события предкомпиляции для слияния XML-настроек и пост-компиляции для слиянияс целевой сборкой.ЗаключениеВ результате диссертационного исследования были выполнены все поставленные задачи и, таким образом, достигнута цель работы.
БиблиотекаAzureLibrary предоставляет готовые универсальные аспекты со сквознойфункциональностью для облачных веб-приложений. Реализованный комплекс программ в Aspect.NET позволяет бесшовно расширять функциональность облачных веб-приложений любой сквозной функциональностью, в томчисле и аспектами из AzureLibrary. Причем, аспекты не обязаны реализовывать всю сквозную функциональность и могут делегировать ее выполнениесторонним библиотекам, компонентам и веб-сервисам. Для улучшения качества исходного кода облачного веб-приложения и повышения степени егоповторного использования, программист также получает возможность выделить некоторые действия в другой проект, воспользовавшись предложенным13набором АОП-рефакторингов, и дополнить его в зависимости от своего проекта.Использовать сервисы платформы Microsoft Azure может любое вебприложение, однако при этом возникает проблема “сквозной функциональности”, когда код обращения к соответствующим компонентам распределенпо всей системе.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
