Тут скорее вопрос тупо "а кде это писать". Если в контроллере - получаем проблемы с повторным использованием. Вот я с этой точки на эти "хелперы" и смотрю.
Почти, но в общем у меня был теоретический вопрос, как это построить в случае DI. Yii тут плохой пример, я его в общем знаю более-менее =)
Ну ведь foreign key же используешь?
FK - это другое. Например, человек нажимает +1, нужно обновить счетчик и сделать запись в логе в базе.. или обновить десять счетчиков. И про транзакцию понятно. Просто где писать то эти деcять find // +1 // save() да еще обернутые в транзакцию? Ясно, что самый примитивный вариант - в контроллере. А если это действие нужно в двух разных контроллерах?
он есть для выолнения лдействий после изменения данных аудита например не обязательно изменение другой модели
именно это я и делаю
изучение матчасти очень полмогает в понимании
понимаю что это но не понимаю зачем это здесь в PHP а это доказывать вам - бремя доказательства всегда лежит на аргументирующей стороне
верно - интуиция великое дело.
внешние ключи constraints они не меняют данные. Если конечно не имелось ввиду касткадное удаление и обновление
Ну да, как вариант. Хотя по сути своей это не модель будет, так как никаких данных не содержит, а хелпер... т.е. как я понял тот самый сервисны слой, о котором говорил fixxxer.
Дело в том что есть MVC как идея - разделяй мухи и котлеты. Тут все понятно - не смешивай
Хотя бы не "замахиваются на Вильяма, понимаете, нашего Шекспира" =))
каши мало ели нанести мне травму тем более душевную. Сам лурк почитываю но смешивать с обсуждением технических вопросов а особенно заменять ответы на них как то некошерно.
самое интересное что эта связь более чем очевидна. Ведь вид когда рендерит себя лучше других знает какие данные для этого нужны в какой момент и в какой последовательности. Поэтому именгно вид должен получать данные с модели.
Да, разумеется. Здесь еще большое влияние имеет сложившаяся организационная причина: версткой занимается отдельный человек, и часто хочется, чтобы итоговые шаблоны получались из той самой верстки минимальными преобразованиями. В десктоп-разработке этот нюанс отсутствует вообще, а тут - вот так. Потому так или иначе хочется ввести еще одну прослойку.
да, это логично
наличие прослоек не проблема а наоборот это структуризирует архитектуру. Просто нужно четко понимать что оно делает и как управляется. Яркий пример - сервера приложений и прочие многозвенные системмы. Но PHP даже не имеет персистентных объектов - это по сути быстрый шаблонизатор с простым и легким скриптовым языком. То что Метт Зандстра попытался перетащить на него паттерны с явы вызывает только сочуствие.
