214-697-723 |
info@mainsource.ru |
(812) 946-31-81
Все контакты
Автор статьи Синцов Роман
Опыт перехода с OpenSource CMS на коробочную UMI.CMS
Данная статья представляет собой мой доклад, с которым я выступал на первом
, проходящем
на Интернет конференции .
Холивар.
Безусловно, каждый разработчик будет хвалить именно ту систему управления, тот язык программирования
и ту операционную систему, к которой привык. Я нисколько не претендую на то, чтобы мое мнение, считалось единственным верным.
У каждого есть своя точка зрения, но я хотел бы рассказать, почему в итоге я выбрал UMI.CMS в качестве основной системы для разработки сайтов.
Длительный путь..
Я имею достаточно богатый опыт разработки бизнес-логики для всякого рода систем управления. Так уж получается, что в большинстве случаев
веб-студии испытывают явный недостаток специалистов, которые могут разбираться в короткие сроки с тем, с чем они раньше не сталкивались.
Всегда можно написать некоторый код напрямую в обход API и вообще архитектуры системы. Однако, лично я такой подход не приемлю, и как показывает
практика, время и трудоемкость, которые будут потрачены потом на обновление и доработку такого вот рода систем, возрастают в разы.
Отсюда мне пришлось поковыряться в совершенно разном коде, разных CMS, начиная от OpenSource-решений, типа Joomla,
Wordpress и самописных движках. Безусловно, также в разработке мне пришлось столкнуться с UMI.CMS и 1С-Битрикс.
И что бесплатно?!...
В самом начале своего пути в направлении создания сайтов и разработки функционала, я предлагал клиентам использовать
бесплатные системы управления, причем я честно был уверен в том, что коробочные решения — это пустая трата денег клиента.
И естественно доволен был и клиент, так как он реально экономил. Также важным аргументом был тот факт, что для Opensource-решений
разрабатывается большое количество платных и бесплатных модулей, которые можно использовать в рамках своих проектов. Для меня лично
и в дальнейшем для нашей компании это тоже было удобно, так как не нужно тратить время на разработку, каких-то решений, практически уже все есть в сети.
Фэил Еррор....
Однако, спустя какое-то время, начали возникать всяческого рода трудности (например, где-то посыпались эксепшены, которые ничем не ловятся,
или стали наблюдаться явные проблемы производительности), о возникновении которых я даже не мог подозревать. В итоге силами разработчиков
приходилось копаться в коде модулей и самой системы управления и устранять баги. Иногда проблемы решались обновлением, а иногда, наоборот,
это приводило к возникновению новых багов.
Первое знакомство.....
И, возможно, так было бы и дальше, стали возникать мысли о написании своей системы управления, которая не будет многофункциональной,
а будет направлена для решения конкретных задач. Но пришлось столкнуться с крупным проектом, для которого было разработано много
уникального функционала, и работает он под управлением UMI.CMS. В рамках данного проекта требовалась разработка нового функционала
и доработки по старому. Так я и познакомился с миром UMI.CMS.
Признаюсь честно, было потрачено достаточно времени, чтобы понять для себя как писать код под UMI. Однако, я считаю, это время
не было потрачено зря. Я остался доволен тем, как подошли к делу разработчики ЮМИ, и мне нравится то, что у них получилось.
Сейчас мы практически полностью отказались от использования OpenSource для разработки Интернет-проектов.
И смещаем акцент с 1С-Битрикс в сторону UMI.
А теперь больше конкретики, почему именно UMI.CMS. Я хочу затронуть весь спектр преимуществ с точки зрения разработчика и с точки зрения заказчика.
Архитектура данных......
При работе с API UMI.CMS мы абстрагируемся от понятия базы данных, ее структуры, нативных sql-запросов,
хотя реально это все используется, но скрыто в глубинах API. Разработчик в терминах Юми работает с объектами.
Вся модель построена на взаимодействии объектов. Для получения объектов из внешнего хранилища используется понятие фильтра-селектора,
который строится добавлением вызовов методов фильтрации. Объекты могут быть связаны между собой иерархически. Чтобы получить нам список красных машин,
мы просто указываем селектору тип объектов — машины, а также его характеристику — красный цвет и все. Селектор внутри своей реализации
в стороне от разработчика строит sql-запрос, исходя из своей модели, и не требует от него знаний в архитектуре хранения данных и обращения к ним.
Реальная сериализация всех UMI-объектов происходит в одних и тех же таблицах. Рефлексия, или отражение, атрибутов объектов и его типа
происходит по служебным полям таблиц, соединяя все представление объекта по ключам строк таблиц.
+/- физической модели.......
С одной стороны, такая физическая организация данных через единое разложение данных очень гибкая и удобная,
так как позволяет динамически добавлять объекты без расширения физической структуры и добавления таблиц (не плодятся таблицы),
все данные имеют единое представление, что позволяет применять и реализовывать одни и те же единые алгоритмы и процедуры обработки данных.
С другой стороны, такая рефлексия требует более сложного построения sql-запроса на получение и сохранение информации об объектах.
Чтобы построить запрос на выборку, нужно создать цепочку JOIN-вызовов с сопоставлением ключей. А это очень сильно сказывается
на эффективности и производительности работы приложения в случае повышения объема данных и нагрузок на обращение к ресурсам БД.
В целом архитектура UMI.CMS не годится для высокопроизводительных систем с большой нагрузкой. Запросы будут выполняться
долго и, тем самым, блокируя и замедляя другие соединения.
Большинство известных мне систем управления имеют упрощенную модель хранения данных, которая подразумевает отображение каждого
типа объектов на свою таблицу в БД. Такое построение позволяет составлять более эффективные с точки зрения производительности
и сложности нативные sql-запросы, но менее гибко и более трудоемко для разработчика для реализации, требуя от него знаний по
созданию таблиц, их организации, оптимизации. Также для каждого объекта нужно писать свои алгоритмы и операции по сериализации и десериализации,
что требует дополнительных усилий и времени для тестирования и отладки.
Возникает вопрос, почему же для меня не имеют значение эти столь серьезные недостатки в организации данных в хранилище. Отвечу так: для сайтов визиток,
некрупных интернет-магазинов, информационных порталов и социальных сетей, угрозы производительности не будет. Большинство проектов
имеют не гигантский масштаб по нагрузкам и объему данных, а поэтому вариант с UMI.CMS позволит решать при достаточном уровне
производительности подобные задачи. А для разработки крупных систем под высокими нагрузками я вообще бы не стал использовать PHP и MySQL,
в такой ситуации я бы выбрал связку Java + Oracle. Но зато для разработки сайтов это удобная модель, так как позволяет
значительно упростить работу, наверняка некоторым программистам такое представление данных покажется неудобным, однако сразу скажут,
что это предельно просто и удобно. За счет этого даже пользователь имеет возможность создать любой объект прямо через админку.
Для этого ему не придется лезть в БД и создавать там новую таблицу, и разбираться, как и что там делать.
В процессе разработки........
Существует достаточно полная документация по API, на сегодняшний момент есть
определенные недостатки примеров, но такая ситуация есть у всех. Могу в защиту сказать, что ребята из «Юмисофт» постоянно
работают над улучшением документации, также развивают свои источники информации: блог, вики и вики-дев. Также наличие «Службы Заботы»
позволяет разрешать затыки и сложности в процессе разработки. Видно, что UMI заинтересованы в своих партнёрах и клиентах,
и всегда идут им на встречу и помогают всеми возможными путями. Могу сказать, что это здорово, так как, возвращаясь например к Joomla,
спрашивать не с кого, необходимо самостоятельно разбираться с возникшими трудностями, а вся серьезная документация, в частности по API,
на английском языке, причем она очень часто меняется, что крайне неудобно.
Коддинг.........
Вряд ли разработчик сможет сходу начать уверенно писать код под UMI, если начнет с ней работать впервые. Но по себе скажу,
что чем глубже погружаешься, тем больше начинает нравиться процесс разработки на основе их API. Отмечу, что UMI думает
о разработчиках и всячески пытается упростить процесс разработки, например, в версии 2.8 появился класс Selector,
который позволяет предельно просто генерить выборки различной сложности.
Интеграция дизайна..........
UMI.CMS, в отличие от например той же Joomla, позволяет максимально просто
внедрять дизайн, а также использовать на выбор два шаблонизатора tpl и xslt. В случае xslt вообще можно
избежать написания кастомных макросов для сайта за счет того, что любой объект системы можно представить в виде xml.
Глазами клиента...........
Наиболее важная часть для клиента — это удобство управления своим сайтом. Если провести аналогию, например с Joomla и
1С-Битрикс, можно с уверенностью сказать, что UMI.CMS фаворит. Видно, что UMI думает о юзабилити,
так как все интуитивно удобно, сейчас у меня есть отзывы клиентов, которые ушли от Joomla и перешли на UMI
и довольны удобством ее интерфейса. OpenSource-решения, я все-таки считаю, разрабатываются скорей для самих разработчиков
и веб-мастеров, чем для потенциальных пользователей. Для клиента в большинстве совершенно все равно, на чем будет работать его сайт,
главное, что он хочет иметь возможность максимально просто им управлять. Я считаю, что UMI справилась с этим успешно.
Финал...........
UMI.CMS — это:
удобно;
эффективно;
интересно;
стабильно;
надежно.
В итоге всего выше сказанного, лично я для себя сделал выбор. На основе применения UMI.CMS можно строить и развивать надежный бизнес
с уверенностью в качестве и высокой скорости разработки. Я надеюсь, что Вы тоже сделаете для себя определенные выводы
после прочтения этого материала.
>>> В целом архитектура UMI.CMS не годится для высокопроизводительных систем с большой нагрузкой. +1000 >>> В случае xslt вообще можно
избежать написания кастомных макросов Неверно. Половина любого нетривиального проекта - кастомные макросы. Из них половина - закрывающая баги системы.
Под кастомными макросами, я имел ввиду те, которые приходиться писать в случае использования tpl шаблонизатора, а вот в случае с xslt я могу получить информацию об объекте не используя таких макросов, также делать произвольные выборки, ну и конечно что не рекомендуется - if, choose, for-each . То есть в данном случае не шла речь о том что используя xslt мне не придется реализовывать свою бизнес-логику :)
Даже в случае с xslt (про tpl вообще молчу - очень неудобный, кто xslt знает, про tpl в umi забывает наглухо) приходится писать кастомные макросы. Вот классический пример: umi не содержит информации о дате создания объекта/элемента, чтобы ее иметь первым делом при начале любого проекта прописываю такой кастомный макрос. Подобных примеров с выводом информации об объекте/элементе тоже десятки. Но в целом согласен: Очень большая часть задач, решаемых ранее кастомными макросами выносится на уровень xslt-шаблона (что и экономически хорошо за счет "зарплата верстуна" vs. "зарплата программера").
214-697-723 |
info@mainsource.ru |
(812) 946-31-81
