Если не секрет, зачем вам делать свой видеохостинг? Рынок уже занят гигантами, получить аудитории и хотя бы отбить затраты будет очень тяжело, если не невозможно.
@kotomyava "наличествующая архитектура и договорённости помогают" - именно об этом я и говорю.
@alekciy речь идёт не только о проектах, допустим на Drupal, но и о самом Друпале, внутренняя архитектура которого, ИМХО, оставляет желать лучшего.
Всё написанное ниже - чистое ИМХО.
Моё мнение, которое я хочу выразить своим ответом и комментариями, в том, что если уровень разработчиков позволяет писать свою CMS, то их уровень так же позволит использовать фреймворк. И что в этом случае лучше начать делать проекты на фреймворке, попутно собирая свой каркас из модулей и компонентов, который позволит собирать стандартные проекты вообще не задумываясь и минимально кастомизировать их под конкретные задачи.
@alekciy теоретически это так, однако по моим наблюдениям фреймворки (речь идёт о Yii, с Symfony опыта почти нет, другие вообще не трогал) имеют стройную, продуманную архитектуру, и разработчики, которые пишут на них стараются ей следовать.
CMS же и сайты сделанные на CMS это трэш, угар и содомия =)
Я допускаю, что есть хорошие CMS и хорошо сделанные на них сайты. Так же я легко могу предположить существование криворуких кодеров, юзающих фреймворки через *опу. Но таких я пока встречал очень мало.
@omun, в данном случае, мне это кажется меньшим злом =)
Твоё решение, основано на том, что "все функции в классах и у них есть общий предок", но не факт, что в данном случае это так. Моё решение более универсально.
@Masterme, нет ничего плохого в том, чтобы "хардкодить" им класса, если это фундаментальная часть приложения (такая, как объект доступа к БД).
@Masterme, "Одиночка (англ. Singleton) — порождающий шаблон проектирования, гарантирующий что в однопоточном приложении будет единственный экземпляр класса с глобальной точкой доступа." (c) Вики
Это не "просто объект, существующий в единственном экземпляре".
Это шаблон, который предполагает:
1. Механизм порождения этого самого единтственного объекта.
2. Механизм контроля его единственности, который не даст создать больше одного объекта.
3. "Глобальную точку доступа", т. е. механизм получения этого самого единственного объекта.
Спасибо, за подробный ответ!
В данный момент рассматриваю ещё один вариант, на который навел меня автор предыдущего ответа - переход на postgres и использование возможностей posgres по работе с json.
Производительность не критична, объемы данных и нагрузки не очень большие (сервис для внутренних задач).
Критична логичность и масштабируемость архитектуры, т. к. планируется сначала, в минимальные сроки, написать и запустить некий базовый функционал, и позже его достаточно сильно расширять и добавлять фич. Не хочется в процессе расширения утонуть в костылях и говнокоде, поэтому я стараюсь продумать всё сейчас, пока изменения архитектуры ещё не так затратны.
Хотя, пока ещё ничего не написано, только проектируется структура, ешё не поздно перейти на postgres, если это действительно даст такие преимущества. Есть проблема в том, что у меня нет опыта работы с ней, а у нашего админа нет опыта её поддержки.
В общем, спасибо за идею, я почитаю про это.
