Пришлось тут намедни ковырять проект, написанный с помощью qcodo framework:
The Qcodo Development Framework is an open-source PHP 5 framework that focuses on freeing developers from unnecessary tedious, mundane coding.
Русскоязычной документации или нет, или я плохо искал. Все, что найдено – 2 статьи на тему qcodo на хабре.
Основная фича qcodo – генерация исходного кода.
Как это выглядит: создаем структуру базы данных, запускаем специальный скрипт. Он генерирует классы для каждой таблицы из базы, при этом анализируя связи между таблицами (inno db конечно же). В соответствии со связями он решает какие будут методы. Генерируется для каждого класса несколько стандартых методов, к примеру такие как load all, load, save и т.д. т.п.Этот код изменять нельзя. От сгенерированных классов делаем наследников.
Далее, если изменяется структура базы, код нужно перегенерировать заново.
Плюс ко всему этот фреймворк генерирует некие стандартые шаблоны для показа данных из базы и их редактирования. (Называется QForms)
Грубо говоря мы рисуем структуру, генерируем код и получаем примитивный web-интерфейс для работы с БД, не написав ни строчки.
Всё это красиво. Но в процессе познания джедайской силы обнаружилась куча грабель:
1) Все данные, прилетающие из базы, qcodo выдает в виде объектов.
Рассмотрим движок интернет-магазина: вы хотите в админке увидеть список покупателей. По умолчанию qcodo тянет из базы этот список покупателей и создает полные объекты. Например в нашем случае в код выплюнется объект покупатель, в нем свойством будет корзина покупателя, просмотренные товары (каждый из которых тоже объект) и т.д.
Имеем в итоге: 10.000 юзеров тянулись из базы около 15 секунд. Почему 10 тысяч? Пагинация как бы, LIMIT. А вот хрен, об этом в следующем пункте. Чтобы ускорить всю эту кухню, пришлось дописывать костыли в виде прямого обращения к базе, и выдирания нужных данных в массив. Пашет очень быстро, но чревато проблемами, если сменится сама структура базы – у нас имена полей в костылях жестко забиты в код.
2) Не вникнув в суть гениального изобретения авторов фреймворка, полез в код проекта. Решил, что так пойму всё быстрее.
В итоге я обвинял во всём потусторонние силы и плохую карму: открываю страницу с товарами – конструктор срабатывает. Кликаю на товар – объект используется тот же самый. Но конструктор не отрабатывает вторично(!). В попытках понять почему сломал моск.
Итак почему: отработали все созданные объекты, сгенерировали html, выплюнули в браузер клиенту. Но перед тем как выплюнуть, заботливо себя сериализровали и запихали в конструкцию примерного вида <input type=»hidden» name=»obj_store» value=»DFGS5wttgEGR45tyEASGSre6%$s….»> ….
И клиенту соответственно выплевывается код с дополнительными xxx килобайтами информации.
Далее, при любом телодвижении клиента, все это добро отсылается обратно на сервер, где происходит unserialize в рабочие объекты, в которых идет дальнейшая обработка.
Отсюда такие тормоза при выводе страницы из первого примера – при первичном создании объектов из базы тянулись все 10к покупателей. И показывались первые 20. Если клиент тыкал на страницу 2 – покупатели из базы уже не забирались совсем – они у нас сериализованы и запиханы в input на стороне клиента.
Вывод: нищие славяне, платящие по трафик должные ненавидеть такие системы априори. Плюс усложняется дебаг и понимание что где лежит. Ибо уместить это все в голове сложновато.
3) Парсинг шаблонов. Html код может генерироваться непосредственно вызовом методов классов, например ownerList->getHtmlSource(). А может лежать в шаблонах. В моем проекте было и то и другое, причем пользовалось крайне интенсивно. Это проклятие кодера.
Сама работа с шаблонами организована так же крайне интересно: отработал некий объект, забрал шаблон, запихал в него данные и вывел себя через echo. (Например та самая таблица). Родительский объект хочет навернуть вокруг таблицы красивую каемочку – для этого он сбрасывает буфер вывода(!!!), а данные из буфера (тот самый сгенерированный html) забирает, обвертывает в свой код и опять делает echo.
Опять таки найти где, что и как выводится чрезвычайно затруднительно, особенно в чужом проекте.
Итог итогов: не топчитесь по граблям.
Post a Comment