Перегляд за місяцем: July 2011
Первая встреча Coldfusion User Group Ukraine
Наша группа до этого момента не проводила открытых встреч. Благодаря совместным усилиями с Flash Platform User Group, мы проведем встречу CFUG #1 вместе с проведением 30-й встречи Flash Platform User Group в Севастополе, 20 августа 2011г. в конференц-зале компании SoftServe по адресу г. Севастополь, ул. Б.Морская, 23.
Планируется несколько докладов по современным трендам в разработке на Coldfusion, и разговоры на тему "Жив ли еще Coldfusion, и зачем он вообще нужен". Кроме того, в программе будет доклад на дизайнерскую тематику и доклад о разработке игр и приложений под мобильные платформы.
Желающие присутствовать на встрече, пожалуйста зарегистрируйтесь здесь: http://fpug.org.ua/meeting/30, а если есть желание дать доклад или сделать презентацию, зарегистриуйтесь, отпишите это в комментариях к регистрации, и напишите на 
Coldfusion и Flash летом в Севастополе, что может быть лучше ?!
Современные фреймворки для качественной разработки на Adobe Coldfusion
(Доклад на встрече .NET User Group Sevastopol 29 июля 2011г., офис компании Softserve, Севастополь)
Фреймворк - это кусок кода, который используется повторно для создания проектов на его основе. Это своеобразны шаблон проектов. Фреймворк призван ограничивать фантазию разработчика, ставить определенные рамки, но взамен фреймворк предлагает хорошие, проверенные архитектурные решения. Следуя вдоль линий, намеченных фреймворком, разработчик в результате получит предсказуемый результат и качественный "робастный" код.
Прежде чем рассказать о фреймворках для Coldfusion, напомним, что представляет из себя этот продукт. Adobe Coldfusion - это сервер приложений, написанный по спецификации JEE, и реализующий язык Coldfusion Markup Language (CFML). CFML - интерпретируемый язык, с помощью которого можно создать веб-сайты любой сложности. Кроме веб-сайтов для Интернета, с помощью Coldfusion легко создавать сайты для корпоративных сетей (Интранетов), благодаря хорошей интеграции с корпоративными серверами, работе с разными форматами данных и протоколов.
Coldfusion появился в 1995 году и обрел популярность во времена "бума дот-комов". В то время сайты делались вебмастерами на HTML, без привлечения скриптовых языков, а единственной опцией было использование Perl. Последний нельзя считать легким для изучения и применения вебмастером - человеком с преимущественно дизайнерским набором навыков. Ответом на это было сделать простой теговый язык наподобие HTML, для быстрого освоения и разработки сайтов. После краха доткомов, Coldfusion несколько растерял популярность на волне популярности ASP и PHP, но выжил благодаря хорошей адаптации в корпоративной среде и в государственном аппарате США. Сейчас происходит второе рождение Coldfusion, и ему есть что предложить миру.
Скорость и легкость разработки на CFML имеет свои обратные стороны. Зачастую, код писался слишком быстро, чтобы выйти на рынок быстрее конкурентов. Качество было забыто, и зачастую код писался непрофессиональными программистами, что не могло отразиться на качестве. Отсутствие общей архитектуры проекта и организации кода, привело к появлению "спагетти"-кода (длинные куски кода, связанные с другими кусками в неразрешимые клубки), в котором сложно разбираться, исправлять ошибки и расширять функциональность. Выделим основные проблемы неструктурированного кода:
- отсутствие общей для проекта структуры кода
- низкая связность кода (low cohesion) - бизнес-логика "размазана" по разным участкам кода в проекте
- высокая связанность кода (tight coupling) - модули кода могут выполнять действия только в связке с другими модулями или внешними данными)
Соответственно, и решение этих проблем лежит в:
- архитектуре - применении паттерна MVC
- повышении связности кода (high cohesion) - организации модулей, каждый из которых реализует одну, заранее хорошо определенную бизнес-функцию
- понижении связанности кода (loose coupling) - делать модули как можно менее зависимыми друг от друга, передавая параметры или обмениваясь сообщениями
Хороший фреймворк призван решить эти три проблемы. Будучи написан опытными людьми, фреймворк предложит решения и направит разработчика по правильному пути. При этом фреймворк должен без изменения подходить вашему проекту, а его код быть легким и оптимизированным. Выбирая фреймворк из нескольких, обратите внимание насколько он хорошо поддерживается, есть-ли у него сторонники, насколько хороша документация.
Опишу несколько популярных фреймворков. Как правило, фреймворки используют такой паттерн для URL:
index.cfm?action=module.procedure
Единая точка входа в приложение - index.cfm, и некоторый "переключатель" - переменная action, в которой задается модуль и действие внутри этого модуля.
Fusebox
Один из ранних фреймворков. В версии 3 использовал CFML для описания модулей, в версии 4 это нужно делать через XML. В 5 версии появилась возможность отказаться от XML в пользу использования CFC. В настоящий момент фреймворк не поддерживается, хотя core-файлы стабильны и пригодны для работы с любым проектом.
Mach-II
Первый объектно-ориентированный фреймворк, представлен с появлением поддержки CFC в Coldfusion MX (2003). С помощью XML-файла фремворк описывает события (events), компоненты CFC, реагирующие на эти события, и views - CFM-файлы, отвечающие за внешний вид. Фреймворк развивается, на нем реализованы многие корпоративные приложения.
Coldspring
http://www.coldspringframework.org/
При работе с многими CFC-компонентами может встать вопрос об их упорядоченном использовании. Например, когда нужно инстанцировать зависимые объекты или синглтоны. Чтобы не следить за зависимостями вручную, фреймворк Coldspring может делать это автоматически. Для этого используется XML-конфигурация используемых объектов (beans), а для вызова конкретного объекта можно использовать лишь запрос к фабрике объектов Coldspring.
TransferORM
Object-Relation Mapping - технология работы с данными в БД с помощью объектного подхода. Один экземпляр (объект) сопоставляется (mapped) одной строке в таблице БД. Это позволяет получать доступ (считывать), добавлять, изменять и удалять записи из БД, не прибегая к написанию SQL-кода. В конечном итоге это экономит время на рутинных операциях. TransferORM - это ORM-фреймворк для Coldfusion 7 и выше. Существующие таблицы БД (и их связи) описываются XML-файлом, по которому в последствии генерируются объекты. Каждый объект содержит поля, соответствующие полям таблицы в БД, а также геттеры-сеттеры для доступа к этим полям. TransferORM поддерживает возврат списков сущностей, поиск по фильтру, поиск по запросу (используется язык TQL - Transfer Query Language).
FW/1 (Framework One)
Новый фремворк, построенный по принципу Convention over Configuration, при котором описание структуры ложится на файловую систему. Фреймворк реализован всего одним CFC файлом, от которого нужно унаследовать Application.cfc нового проекта. Фреймворк реализует паттерн MVC таким образом. Контроллером модуля является один CFC, находящийся в папке /controllers, в этом контроллере определены методы данного модуля. Для доступа к внешним данным можно использовать службу, которая также реализуется через CFC в папке /services. После выполнения метода контроллера, данные собранные в контроллере и службе, через переменную rc передаются дальше, во view, который лежит в соответсвенно папке views/module/procedure.cfm. Для облегчения дизайнерского труда используются шаблоны, которые лежат в папке /layouts и могут иметь три уровня вложенности. Вот иллюстрация, как происходит вызов и сборка конечной страницы:
Минимально необходимым файлом для создания приложения на FW/1 является /views/module/procedure.cfm. Остальные файлы, включая контроллеры, сервисы и лэйауты, необязательны. Framework One подкупает своей простотой использования и скоростью работы.
Заключение
Описанные фреймворки - не единственные, но популярные, которые я бы лично рекомендовал для любого проекта. Мой личный фаворит - FW/1 - за его легкость и простоту. Используя наработанные библиотеки классов (CFC) в проекте на базе FW/1, я обычно использую Coldspring для описания зависимостей между классами в библиотеке, а также TransferORM для упрощения рутинных операций. Для сложных запросов я не прибегаю к помощи TransferORM, чтобы не усложнять код; я пишу обычный SQL-код и хранимые процедуры. Применять тот или иной фреймворк нужно осмысленно, примеряя его возможности к потребностям конкретного проекта и конкретной команды.
Дополнительное чтение по теме:
http://www.aliaspooryorik.com/blog/index.cfm/e/posts.details/post/oo-and-fusebox-no-xml-141
http://www.adobe.com/devnet/coldfusion/articles/frameworks_intro.html
RSS