Здравствуйте, Дм.Григорьев, Вы писали:

ДГ>Прежде всего, по причине невозможности кеширования объектов между HTTP-запросами, и по причине отсутствия реализации Hibernate для PHP, все запросы приходится оптимизировать вручную.

Во-первых, кэширование можно и самому (если уж очень припрет) сделать. Во-вторых, не вижу связи между кэшированием и необходимостью оптимизации запросов.

ДГ>Раскладывать вручную оптимизированный запрос в "правильную" объектную модель — занятие для больших оригиналов. Нужны очень веские причины, чтобы заниматься подобным извращением.

Частично соглашусь. Вручную гидрировать "правильную" объектную модель и правда занятие не из приятных. Однако же в случае, когда классы Domain Model представляют собой просто DTO на стероидах (чего достаточно для простых приложений), делать это, по-моему, не так и сложно.

ДГ>Далее. Все результаты SQL-запросов где-то используются, верно? Так случилось, что большинство результатов просто отдаётся клиенту (исключения — какие-то проверки перед модификацией базы). А теперь смотри: результаты используются в XSLT-преобразовании.

Сам с таким подходом не сталкивался, но сдается мне, что при более-менее сложной верстке этот XSLT будет феерически объемным. Плюс в HTML редакторе его так просто и не посмотришь.

$menuManager->getMenuForUser(...);
$menuManager->getMenuForAdmin(...);
$menuManager->getMenuForLoggedOut(...);

Если я правильно понял логику, то MenuManager получается очень перегруженным и у него образуется слишком большая зона ответственности — и получение объектов из БД, и разруливание вопросов с полномочиями. А сие не есть правильно .

Кроме того, вот это:

ДГ>И поэтому я должен очень внимательно подходить к тому, какие столбцы я отдаю в XML-ответе. Юзеры, админы и незалогинившиеся посетители очень часто получают совершенно разные наборы столбцов. В результате я вынужден либо генерировать SQL-запрос динамически, либо дублировать его в разных вариациях для разных точек входа и разных юзеров/админов/прочих.

тоже смущает. Насколько я могу понять из приведенного тобой выше по ветке кода (типа, "select id, uri, menutitle from {PREFIX}pages where parentid=? order by sortorder"), ты очень сильно завязываешься на имена столбцов — они у тебя есть и в тексте запроса, и во всяких индексаторах, и в XSLT. По мне, так это дюже нехорошо.

Если же использовать какие-никакие классы-DTO, то в общем случае получается, что для разных типов пользователей (админы, простые смертные и т.д.) требуются разные DTO с разным набором полей. Получаем экспоненциальный рост количества классов.

Получается, что для упрощения своей же жизни все вопросы отображения и сокрытия той или иной информации должны быть решены на уровне View'а (если говорми про MVP/MVC). Но тогда выходит, что либо придется использовать какой-нибудь шаблонизатор (из оных для PHP знаю только Smarty), либо делать все XSLT-преобразования на сервере.

ДГ>С предложенным тобой делегированием сам скрипт index.php становится неприятным промежуточным звеном между index.xsl и сильно, но неочевидно связанных с ним методов каких-то объектов-менеджеров.

Это не объекты-менеджеры с ним связаны, а index.php связан с ними -- а это большая разница. И связь эта, при продуманной архитектуре, очевидна и несильна.

ДГ>А уж если ты попытаешься вынести генерацию, скажем, списка пользователей по сложному условию (или любой другой нетривиальный SQL-запрос) из search.php (где он выглядит вполне уместно) в какой-нибудь $userManager, то в итоге получишь совершенно расчудесный вызов типа $userManager->getUsersByConditionForAdmin($twenty, $filter, $parameters, $which, $are, $impossible, $to, $remember, $and, $very, $hard, $to, $specify, $without, $mistake). Ну и нахрена козе боян?

Вот с этим соглашусь -- сам для себя никак не могу толком сформулировать подход решения этой проблемы. Получается либо Query By Example, либо класс-генератор запросов (строго типизированный) либо да, такой вот огромный метод.

ДГ>Короче говоря, я просто использую другой способ декомпозиции — модульный, а не объектный. И на простых и средней сложности проектах, в условиях налагаемых языком PHP ограничений, этот способ гораздо проще и эффективнее объектов.

Быть может. Насчет эффективности только я сильно не согласен. Разницы между 0.05 секунды и 0.5 секунды (такой оверхед надо еще постараться получить) пользователь вряд ли заметит.

ДГ>У меня было предостаточно времени на эксперименты — могу честно сказать, что данный подход выстрадан на не одном десятке проектов (включая контент-сайты, службы знакомств с форумумами, блогами и интернет-магазинами — типовые задачи, и в целом далеко не самые тривиальные).

Ну неужто в интернет-магазинах и службах знакомств ты текст запроса тоже в коде писал?

ДГ>И я готов поспорить, что твои ООП-заморочки (так называемые "упрощения") приведут только к усложнению кода и существенному снижению его эффективности.

Эффективность -- это в смысле быстродействие? А как же преждевременная оптимизация -- корень всех зол?