Search

Rss Posts

Rss Comments

Login

 

Разработка Flex RIA с помощью микроархитектуры Cairngorm. Часть 1: Введение в Cairngorm

Авг 23

Автор: Steven Webster
Часть 1: Введение в Cairngorm

Этот цикл статей, состоящий из шести частей, посвящен Cairngorm – микроархитектуре с открытым исходным кодом и адресован Flex разработчикам. В нем я хочу объяснить внутреннюю суть Cairngorm, подход к проектированию на основе Cairngorm, а также описать те проекты, реализация которых на основе Cairngorm может быть наиболее успешной.
На примере Cairngorm Магазина я объясню подход Adobe Consulting к анализу, оценке и разработке насыщенных интернет-приложений (RIA) на основе Cairngorm. Я также объясню идеи, заложенные в Cairngorm и мы вместе с вами создадим с нуля Интернет-магазин.
В последней статье, я продемонстрирую одну из многих выгод, которую получают разработчики, основывая свои RIA приложения на Cairngorm, с помощью добавления новой функции в готовый Интернет-магазин.
Конечно же, Cairngorm это не единственный способ построения насыщенных Интернет приложений. Однако Adobe Consulting помог многочисленным заказчикам и партнерам успешно реализовать масштабные проекты на Flex, основываясь на уже имеющихся разработках заказчиков и информации изложенной в этой статье.
Это введение раскроет вам проблемную область Cairngorm, начиная с мотивации разработки на Cairngorm и его концепций до проектирования своего собственного приложения на этой, признанной многими авторитетами, и поддерживаемой микроархитектуре.
Вместо ковыряния в коде, первая часть вводит вас в проблемную область архитектуры Cairngorm и дает понимание ее основ. Я расскажу о фреймворках и объясню разницу между программными фреймворками и архитектурными. Потом я произведу обзор паттернов проектирования и подведу вас к пониманию микроархитектуры. В заключении я вкратце расскажу о необходимости Cairngorm, его начало и историю.
В частях 2-6 мы с вами будем разрабатывать клиентскую часть приложения для розничной торговли с помощью Flex и Cairngorm на основе существующей J2EE серверной инфраструктуры.

ЧТО ТАКОЕ ФРЕЙМВОРК

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

Программные фреймворки

Flex есть яркий пример программного фреймворка. Действительно, продукт Flex 2.0 имеет все отличительные качества программного фреймоворка (который Adobe внутри называет «app model») в своей архитектуре. Фреймворк Flex 2.0 предоставляет большой набор классов с высокоуровневой функциональностью, которые разработчик может использовать в собственном проекте. Например, Flex 2.0 предоставляет API для работы с Collections Data (сложные типы данных, состоящие из других типов - прим. перев.), которые дают возможность управлять коллекциями данных. Разработчик может собирать необходимые данные в единый объект, который будет характеризовать его приложение. И конечно же Flex, как и любой другой программный фреймворк, предоставляет возможность управления историей, управление разметкой проекта, управление видом курсора, перехват исключений, возможность интернационализации, журналирования и тому подобное.
Если фреймворк предоставляет библиотеки высокоуровневых классов с большой степенью гибкости их использования, или когда фреймворк предоставляет сервис уровня приложения, и может использоваться в различных проектах – я называю такой фреймворк «программным».
Еще один хороший пример программного Фреймворка это фреймворк FAST, который Adobe Consulting довольно успешно использует в проектах своих клиентов и партнеров. Фреймворк FAST (см. статью Джона Беннетта «Быстрая разработка с помощью Flex Application Toolkit» http://www.adobe.com/devnet/flex/articles/fast_userguide.html) предоставляет программные службы для логирования и трассирования, расширенных пользовательскими данными библиотечных RPC классов в Flex 1.x.

Архитектурные Фреймворки

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

ИСПОЛЬЗОВАНИЕ ПАТТЕРНОВ ПРОЕКТИРОВАНИЯ

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

Привлекательность паттернов проектирования

А теперь внимание: когда разработчик сталкивается с паттерном проектирования, каталог реализаций этих паттернов оказывается очень мощным инструментом в решении поставленной инженерной проблемы. Еще чаще разработчик сталкивается с целым клубком задач и пытается изобрести новый паттерн. Здесь применима старая пословица «Если у тебя в руках молоток, то все кажется гвоздями». В этом случае вы услышите термин «перегрузка паттерна», что означает, что разработчик отказывается от разработанного класса и отказывается от сотрудничества, а пытается все впихнуть в Factory (Фабрика), Flyweight (Приспособленец), Observer (Наблюдатель), Decorator (Декоратор).
Однако правильное использование паттернов проектирования приносит большую выгоду. Паттерн проектирования не просто дает решение проблемы, а указывает направление реализации. Например, если вы видите в коде паттерн Singleton (Синглтон, Одиночка), вы сразу понимаете, что будет всего один экземпляр этого класса. Точно также, если вы видите паттерн Factory, вы понимаете, что существует некое множество других классов, созданием которых будет заниматься эта фабрика.
Поднимаясь по уровням технической архитектуры – с начального уровня детализации до высокоуровневой системы, скажем, вертолета – вы можете увидеть процесс разработки в виде повторяющегося процесса. Так же как Мандельброт (основатель фрактальной геометрии – прим. перев.), вы можете опознавать структуры более высокого порядка на основе описания более примитивных структур. Также и паттерны объединяются повторением, давая решение более высокого уровня для более сложных проблем.

Микроархитектура как объединение паттернов проектирования

Шаблон проектирования дает конкретное решение конкретной проблемы. Например: паттерн Синглтон дает нам уверенность в том, что будет всего один экземпляр этого класса. Набор паттернов, последовательно взаимодействующих друг с другом, дают решение более обширной задачи. Например: «Как мне получить жест пользователя и убедится что класс рабочего (паттерн Worker – прим. перев.) берет ответственность за исполнение»? Или: «Как мне сосредоточить бизнес логику, которая может использоваться в разных контекстах приложения на стороне клиента, даже если это вызывает различные службы на сервере»?
Когда вы начнете объединять шаблоны проектирования в системы более высокого порядка, пусть даже весьма примитивные по своему действию, вы будете называть это «микроархитектурой».
Теперь перейдем от абстрактных рассуждений о программных фреймворках, архитектурных фреймворках, паттернах проектирования и микроархитектурах к нашей теме. Когда Adobe Consulting говорит о фремворке Cairngorm, мы подразумеваем архитектурный фреймворк – отправную точку для технической архитектуры, достаточно абстрактную чтобы применять ее в различных проектах Flex RIA средней и большой сложности.
Более того, когда мы говорим о фреймворке Cairngorm, мы не имеем в виду какую-то монолитную архитектуру, которая ограничивает вашу свободу как разработчика ради решения технической проблемы. Скорее мы подразумеваем следующее:
- компактный программный фреймворк, который предусматривает некий целостный и последовательный подход к разработке Flex RIA
- использование небольшого количества необходимых паттернов, которые в процессе взаимодействия являются чем-то большим, нежели просто набором шаблонов
- микроархитектура для разработки RIA – отправная точка для технической архитектуры, предназначенной для решения задачи тем же успешным способом, который использовался неоднократно
И как вы увидите ниже, это все благодаря тому, что «мы стоим на плечах гигантов».

КРАТКАЯ ИСТОРИЯ CAIRNGORM

Софтверная консалтинговая компания iteration::two, которую я основал совместно с Алистером МакЛеодом, хорошо зарекомендовала себя в среде разработок программного обеспечения на основе J2EE и ее подходы к решению задач оказались подходящими для разработок RIA. Мы применили свои наработки для реализации RIA с помощью Flash, Flash Remoting и J2EE – в тот ранний период истории развития RIA, к которому мы так нежно и с ностальгией относимся, как C++ программисты относятся к программированию на ассемблере 6809.
Заимствуя часть шаблонов проектирования из библиотеки «Core J2EE Pattern Catalog» Sun Microsystems (http://java.sun.com/blueprints/corej2eepatterns/Patterns/index.html), мы первыми представили эти паттерны вниманию Flash сообщества в нашей книге «Reality J2EE: Architecting for Macromedia Flash MX» (Pearson Education, 2003). Совместно с выходом Flash MX 2004, мы описали эти паттерны в главе «ActionScript 2.0 Design Patterns for RIA Development» в «Macromedia Flash MX 2004 ActionScript 2.0 Dictionary» (Macromedia Press, 2003).
С развитием RIA технологии от дизайнерского подхода к разработке до декларативной программной модели Flex, большая часть идей применения этих паттернов осталась. Однако программная модель Flex дает нам более элегантный способ для воплощения этих паттернов. Более того, некоторые паттерны, имевшие большую ценность для Flash RIA разработчиков (например, паттерн ViewHelper), утратили свою значимость, и были нами заменены другими (например, ModelLocator), свойственными для Flex.
На форуме MAX 2004 мы заявили свое намерение о создании фреймворка Cairngorm, как проекта с открытым исходным кодом для Flex. Это решение нашло широкую поддержку в среде программистов.

ЧЕМУ ВАС УЧИТ CAIRNGORM

Микроархитектура Cairngorm предъявляет три основные требования, которые мы всего советуем нашим клиентам и партнерам как лучшую практику программирования:
- Обрабатывать пользовательские жесты на клиенте;
- Инкапсулировать бизнес логику и взаимодействие с сервером;
- Управлять состоянием приложения на клиенте и отображать это состояние в пользовательском интерфейсе.
Cairngorm реализует микроархитектуру (т.е. набор паттернов), которая последовательно решает эти повторяющиеся задачи проектирования.
После того, как вы прочтете этот цикл статей, вы научитесь следующему:
- Как паттерны Front Controller и Command реализуют микроархитектуру «Service to Worker», которая слушает пользовательские запросы и отвечает на них;
- Каким образом взаимодействуют паттерны Business Delegate и Service Locator, так что вы можете повторно использовать бизнес логику, а также инкапсулируют ее, позволяя разработчикам клиентской и серверной части легко связать взаимодействие приложений на сервере и клиенте, не зависимо от технической реализации серверных служб, будь то WebService, Enterprise JavaBeans, ColdFusion, или REST-архитектура использующая XML через HTTP;
- Как паттерн Value Object из J2EE сотрудничает с паттерном Model Locator, давая элегантное решение того, каким образом хранить состояние на клиенте, с насыщенным и анимированным пользовательским интерфейсом.

ТЕКУЩЕЕ СОСТОЯНИЕ CAIRNGORM

Текущая версия Cairngorm – 0.99 (на момент 2006 года; сейчас (2008) уже есть версия 2.2.1 для Flex 3 – прим. перев.). Он никогда не будет выпущен в версии 1.0, поскольку iteration::two была вовлечена в ряд поглощений, сначала со стороны Macromedia a потом и Adobe Systems. Более того, с выходом Flex 2.0, ActionScript 3.0, численных изменений в основе фреймворка Flex, множества новых потрясающих служб (включая Flex Data Services), и эволюцией самого Комитета Cairngorm (а сейчас он является частью основных консультантов и инженеров Adobe, и большим сообществом вокруг Adobe) – Adobe Consulting сфокусировалась назад выпуском комплексного релиза Cairngorm 2.0, который бы использовал всю мощь Flex 2.0.
Но, не смотря на это, ключевые концепции Cairngorm остаются теми же. Изменилась только реализация внутренних механизмов для использования новых свойств Flex 2.0, например, таких как Flex Data Services, Flex RPC Services. Для тех, кто уже работает с Flex 2.0 в Adobe Labs, мы регулярно выпускаем альфа релизы Cairngorm 2.0.
Замечание: в заключительной части этого цикла, я обсуждаю критерии принятия решения для использования Cairngorm. Мы ни в коем случае не убеждаем, кого бы то ни было в том, что Cairngorm это единственный способ построения RIA приложений. Мы даже не настаиваем на том, что это является лучшей практикой проектирования. И, конечно же, кто-либо может предлагать свои подходы, которые будут противоположны рекомендациям Cairngorm.
Все что мы требуем от вас, это сначала попытаться понять саму проблему, которую пытается решить Cairngorm, до того как начинать решать ее с помощью Cairngorm. Если вы только начинаете свое изучение Flex 2.0 для построения RIA приложений, я настоятельно рекомендую вам сначала освоить все то множество новых инструментов и техник этой технологии, прежде постижения сложных моментов связанных с Cairngorm.
Нельзя сказать, что Cairngorm очень сложный. Напротив, но вы должны уже уметь строить простые RIA приложения, которые не требуют каких-то специальных микроархитектур, для того чтобы вы смогли ощутить преимущества использования Cairngorm.
Прочтение вами частей 2-6 этого цикла позволит нам удостовериться, что и новички и опытные Flex программисты одинаково понимают проблемы создания RIA, которые решает Cairngorm. Мы хотим объяснить вам как можно доходчивее, и приведенные примеры кода элегантного решения с помощью Cairngorm, надеемся, помогут вам эфективно использовать Cairngorm для решения своих задач.

ЧТО ДАЛЬШЕ

Задачей этой статьи было ознакомить вас с микроархитектурой Cairngorm, объяснить двойственность понятия «фреймворк», зачем вам использовать фреймворк, истоки и будущее фреймворка Cairngorm.
Cairngorm это архитектурный фреймворк, предоставляющий готовую техническую архитектуру, на основе который возможно построение собственной, более сложной, проблемно-ориентированной архитектуры.
Основывая свое приложение на Cairngorm, вам не придется решать некоторые простые и фундаментальные задачи программирования. Например, как получить пользовательский жест, как получить ответ от сервера на запрос бизнес логики, и так чтоб это решение было элегантным и масштабируемым. Также вам не придется решать, как лучше управлять состоянием на клиенте в сложном и насыщенном приложении.
Я также немного рассказал об инженерной дисциплине программных шаблонов проектирования, и каким образом iteration::two заимствовало их из тех, что мы использовали как J2EE разработчики, которые также применимы для RIA. Обычно панорамный обзор программной архитектуры помогает понять разработчикам, какое взаимодействие паттернов заложено в его основу. Явление взаимодействия паттернов, обычно именуют микроархитектурой, каким и является фреймворк Cairngorm.
Когда я оказываю консалтинговые услуги, я часто говорю, что отличие теории от практики состоит в том, что теоретически, нет никакой разницы между теорией и практикой. В части 2, я отойду от рассуждений о шаблонах проектирования и микроархитектуре, а представлю Cairngorm с точки зрения четырех преимуществ, которые он предоставляет:
- хранение состояния на клиенте
- архитектура пользовательского интерфейса
- разработка только характерных черт приложения
- вызов серверных служб
Во второй части, будет практически показано, как мы используем Cairngorm в процессе создания приложения и какие проблемы он решает. Вы увидите целостный подход к созданию масштабируемого, сопровождаемого и безотказного насыщенного Интернет приложения с помощью Flex.

Нужен ли мне Cairngorm?

Авг 07

Несмотря на то, что мне хочется много сказать «за» и «против», в целом мой ответ НЕТ. Т.е. на вопрос «нужен ли мне Cairngorm, чтобы эффективно программировать на Flex?» можно утвердительно и смело ответить «Нет, не нужен». Вы действительно можете создавать эффективные, быстрые (как в разработке, так и в работе) приложения без использования Cairngorm.

Немного лирики

Уверен, что вы знаете, что такое Cairngorm, но, совершенства ради, хочу еще раз повторить всем известные факты. Да и повторение – мать учения.
Cairngorm – это фреймворк, реализующий паттерн MVC для Adobe Flex. При этом:
фреймворк – это программный каркас, паттерн – шаблон проектирования, MVC – паттерн Модель-Вид-Контроллер.
Те, кто уже напрограмировался в своей жизни, хорошо понимают термин фреймворк – каркас. Т.е. нечто, позволяющее на его основе строить свое собственное решение поставленной задачи. Но при этом фреймворки бывают разные по своей сути. На сколько мне известно терминов определяющих их виды не существует, возможно из-за ненадобности, но я бы хотел поделится своими мыслями по этому поводу, по тому как это может помочь скорейшему понимаю сути вопроса. И так, IMHO можно выделить как минимум два типа фреймворков: компонентные и концептуальные.
Отличным примером компонентного фреймворка может служить сам Adobe Flex. Flex – это большая библиотека классов, представляющих собой программные компоненты для визуального представления данных. При этом как их использовать, как их связывать между собой решаете полностью вы – разработчик. Вы решаете какие именно взять компоненты, какие нужно изменить под нужды вашей задачи, какие нужно будет написать заново, а так же вы определяете их взаимодействие – внутреннюю логику работы вашего приложения.
Примером концептуального фреймворка, конечно же, будет Cairngorm. Он не дает вам никаких новых компонентов для визуализации данных, он дает вам СТРУКТУРУ вашего приложения. Вы нанизываете на его каркас вашу бизнес логику, а он вам гарантирует что все заработает и будет работать как часики. В этом смысле Cairngorm ничего не дает вам, и даже более того – постоянно вас ограничивает.
Но сказать, что Cairngorm вообще ничего не дает, будет не справедливо. Он дает вам заранее известную структуру приложения (и не только известную вам, но и любому другому программисту, знакомому с Cairngorm), и заранее известную логику работы. Первое вам сильно облегчает жизнь, когда спустя некоторое время вам надо добавить новый функционал к вашей программе, или немного изменить поведение. Вы легко справитесь с этой задачей, поскольку вы постоянно работаете с Cairngorm и не просто помните, но знаете, что и где искать. Также не мало важно, что с этой задачей справиться и любой другой программист, хорошо знакомый с Cairngorm. Второе свойство вам несказанно поможет при отладке приложения, когда вы наткнулись на какой-либо сбой в программе, вы четко знаете к какому модулю предъявлять претензии, поскольку Cairngorm лишает вас возможности сделать что-либо двояким способом. Ну например, вы не можете выполнить запрос данных у сервера кроме как в команде (такой паттерн внутри Cairngorm).
Представьте теперь, что вы пришли на новую работу и в ваши обязанности входит поддержка старого приложения, которое написано на Cairngorm. Если вы хорошо знакомы с Cairngorm – это не составит особого труда. Или с другой стороны, вы – ведущий специалист, в ваши обязанности входит много чего и еще поддержка кучи старых проектов, но на Cairngorm. Все что вам нужно – это искать юных спецов со знанием Cairngorm. Короче все в шоколаде.

На счет вопроса «а зачем мне учить еще один фреймворк?»

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

Сумум бонум

Т.е. получается что я сказал сначала «Нет», а потом доказал что таки «Да». Я хотел сказать, что даже если вы не собираетесь использовать Cairngorm в своей работе, то знание его все равно будет вам полезным.

А что если

Ясное дело, многих вновьподошедших мучит вопрос «а что лучше?». Ведь Cairngorm не единственный MVC паттерн для Flex. Есть же еще и PureMVC, который хорошо развивается как проект. Думаю, что каждый должен решить этот вопрос сам для себя, что лучше использовать. В конце концов, разница не большая, главное, что есть изначально определенная структура вашего приложения.
Лично мне известны две основные трудности Cairngorm: сложность и куча мелких файлов. Первое побеждается опытом, второе (опять же исходя из опыта) все же лучше чем пара очень больших файлов.
Насчет PureMVC, я знаю что у них есть оберточные функции для событий Flex. Полезность их сомнительна, хотя вред не доказан. Это связано с тем, что PureMVC изначально задумывался как MVC для любого языка. Но событийная модель встроена в сам Flash, поэтому строить свою систему событий кажется бессмысленным.
В Cairngorm тоже есть Cairngorm-события, но это не что иное, как правомерное использование событий Flash – когда программист создает свое собственное событие и упаковывает туда свои данные (payload), но распространением (propagation) его занимается сам Flash.
Это, конечно, тема большая, может быть, я напишу об этом отдельную заметку. Для меня основным фактором при выборе MVC фреймворка для Flex было то, что Cairngorm создавался специально для Flex.

Вот.