@Sputnik23 кто вам мешает:
1. сделать человеческий билд, зазиповать, залить на сервак по scp, распаковать. Можно автоматизировать через Phing.
2. запустить composer на сервере.
@Boniface собственно в этом и есть основной плюс. Проблемы производительности решаемы. Так же хранение части логики в процедурах понижает переносимость кода и усложняет поддержку и деплоймент.
@kapnod просто насколько я помню систему таксонометрии вордпресса, там все, картинки, посты и категории... все пишется вроде как в одну таблицу. Ну или там есть еще какие-то нюансы, так что при создании категории создается еще куча всего, что увеличивает разбежку между id-шниками. + версионизация есть. что тоже добавляет. Словом, точно сказать и предсказать какой id будет следующим сходу я не могу.
@Glush потому что у вас html в функции load_news, что убивает смысл шаблонизации. Идея шаблонизации и вообще разделения представления от логики именно в том, что логика дает вам данные, контроллеры решают какому представлению его скармливать, представление формирует html. То есть о наличии и того и того знают только контроллеры, но они не знаю как хранятся данные, ничего о логике и ничего о том как формируется представления. Тогда в этом смысл есть. А так можно просто в plain php писать и ничего от этого не поменяется.
@maxkh вам нужно на основе websockets тогда свой протокол реализовать, и уже в нем все разграничивать. Просто добавить небольшой заголовок дополнительный, о том к какому компоненту относятся сообщения.
@nepster09, я не знаю о каких вы фреймворках говорите, скорее всего о штуках типа yii, использующий по всему приложению сингелтон.
Проблема статических методов в том (в контексте php) что вам приходится в коде использовать определенный класс, и таким образом вы уже делаете ваш класс зависимым от какого-то другого. В фреймворках типа yii обычно все это превращается в очень сильно связанную систему. Да, опять же проблем для тестирования это не составляет (все же фасады/сингелтон yii используются как сервис локатор скорее, так что сервисы можно мокать), но все же при поддержке проекта иногда мешает.
Конечно возможно. Вообще ваше приложение не должно знать что оно использует Doctrine в качестве доступа к хранилищу. Просто пишите сервис, который управляет всем как вам хочется.
Я просто слабо представляю как вы хотите сделать, то есть как бы вы хотели в идеале управлять сущьностями при использовании EAV, как хотите задавать значения и т.д.
@xlamys не записывайте сразу в массив, а ставьте в очередь. При определенной длине очереди выпоняйте запрос. Удобнее запись в базу инкапсулировать в отдельную функцию/метод.
1. сделать человеческий билд, зазиповать, залить на сервак по scp, распаковать. Можно автоматизировать через Phing.
2. запустить composer на сервере.