Вот о синглтонах я и говорил. Они очень редко нужны в вебе. Вернее, я бы даже сказал, в 99% случаев, они являются симптомом плохой архитектуры.
Теперь о "хранилище". Какой смысл "минимизировать" запросы к БД, которые делаются по примари индексам? Какой от этого профит? Ты можешь придумать задачу в вебе, в которой имеется 2+ "виджетов", которые, в свою очередь, могут отображать одинаковую инфу ?
И третий, последний вопрос. Что, если тебе нужно будет засунуть какой то свой виджет своей КМСки, в чужой код ? Такие задачи очень часто возникают. А два виджета ?
Хм. Первый раз слышу, что бы одиночки были "плохим тоном". Одиночки нужны тогда, когда нужно обеспечить уникальность объекта, в случае, например тип "core" и я не думаю, что это как-то зависит от типов проекта. Да, мне интересно, конечно услышать в чем это плохо, а главное как без них обойтись.
По поводу второго - это применение "кусков" из этой системы в других проектах. Что бы ответить на этот вопрос, я слегка объясню суть.
Загрузчик, в частности - /core/core.php обеспечивает загрузку всех классов, и все. Сама система начинает работать только после того, как выполняется первый запрос интерфейса модуля
($controller = core::getInstance()->modulesInterface()->start())
По сути этот запрос на вызов интерфейса доступа запускает всю систему, создаются множество объектов, но, лишь те, которые понадобились. Так, если посмотреть цепочку, то при запуске модуля, создает обект типа urlInterface, который начинает парсить урл (описан в конструкторе). Задача парсинга урлы на всем этапе будет всего один раз, это обеспечивает родитель core, который синглтон, далее, если нужно рождается обект типа languageInterface и так далее.
Сама система на начальном этапе загрузки вообще не пораждает обектов, так, если не будет необходимости обратиться, скажем к usersInterface из любой части приложения (будь то модуль, шаблон или виджет), то он так и не будет рождает, по сути это своего рода набор инструментов в гараже, они есть, но могут и не понадобиться, при этом они не мешают. За все это отвечают именно интерфейсы доступа.
Кроме того, доступ к интерфейсам и их методам позволяет вообще не задумываться о том, были ли они инициализированы ранее или будет ли использоваться позже, тем самым, я избавляю себя от лишных мыслей, при этом, я уверен, что они есть. Как говориться, Ду эз ай сей!
Использование виджетов в сторонних проектах. Во-первых, я сомневаюсь, что большинство систем вообще поддерживают подобные интеграции, но давайте представим, что у меня появилась такая задача. Вся система делится на модули, в которых есть контроллер, модель и вид, при этом, контроллер и модель модели отвечают только за реквисты, все остальное лежит на плечах аггрегаторов и самих типов. Так, например, если где-то в чужом коде мне понадобилось использовать непосредственно объекты (т.е. те данные, с которым я буду работать), скажем country и city, то мне будет достаточно создать новый класс типа countryPHPbb который унаследуется от типа country. В этом классе, скорее всего, я опишу лишь изменения, касающиеся записи объектов и все. Фактически, эти объекты изолированы от системы в целом, и являются независимыми.
По поводу хранилища надо делать замеры.
