то что нету аргументов? Ну так это в изначальное условие и входило. Однако это не мешает перегружать оператор и перенаправлять запрос на другой объект. (возможно выразился неточно...). Проблема в этом случае только одна — в моей реализации данные, которые должны быть приняты или выданы через оператор -> находятся, к примеру, в массиве. Решение которое я нашел по большей части решает эту проблему.
По сути все изменения которые необходимо сделать для более мение стабильной работы фреймворка можно сделать просто перегрузкой 2-х или 3-х функций в классе YII, который по умолчанию пуст и является наследником YiiBase. Остальные классы, если не вдаваться в вопрос оптимизации нагрузки, в изменениях не нуждаются. Касательно кеширующего слоя — у YII и так мощная система кеширования, а в новой версии появился таковой в компоненте CActiveRecord — что довольно ощутимо снижает прожорливость. В любом случае надо экспериментировать.
YII достаточно гибкая система что бы реализовать на ее основе любой функционал. Конечно большая масштабируемость увеличивает затраты ресурсов. Но отказываться от CActiveRecord или CUrlManager я бы не хотел — слишком мощьные инструменты. Остается лишь вариант переписать базовые классы. Или же портировать эти компоненты под свой фреймворк (благо лицензия позволяет использовать фреймворк или его компоненты в любых целях).
Собственно вопрос состоял в том, что думают программисты при работе с такими «монстрами» — что бы они хотели видеть, какую структуру и какие плюшки облегчающие жизнь. Пока я видел лишь пару вариантов идеальных для разработки но они жрут много ресурсов (чем-то приходится жерствовать). Конечно спасает кеширование, но иногда бесит отсутствие золотой середины между удобством и производительностью. Как вариант написать что-то типа «предкомпиляции» узких мест — когда то что пишется на уровне API системы склеивается и упрощается для уменьшения количества абстракций.
В таком случае вы должны предоставлять возможность посмотреть исходник лишь для потенциального заказчика. Тобиш в вашем портфолио будет разделение на то, что можно смотреть, и что нельзя без предварительного разрешения вами. Конечно полностью это не обезопасит, но хоть немного спокойнее будет.
Со всем согласен но не могли бы вы остановиться на втором пункте чуточку поподробнее? Допустим CMS основана на фреймворке. Согласен, размер дистрибутива (если его предварительно не уменьшили) может достигать тех же значений что и остальные CMS. Но как по мне это не сильно большая проблема при более менее грамотной системе подключения файлов (допустим YII).
А вот вопрос о «толстом ООП» и MVC меня немного смутил… Нелегко разобраться в конкретной реализации или в целом? Как-то паттер MVC призван все же более упростить разработку. Да и для меня разобраться с хорошо написанными приложениями было намного легче. Можете пояснить?
