Нужен ли мне 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.
Вот.