В статье вы упомянули, что с помощью API Метрики можно к каждому заказу прикрепить информацию о посетите — откуда пришел, из какого он региона и т.п. Однако сколько не изучал документацию — как вытащить данные из текущей сессии не нашел. Подскажите пожалуйста, куда копать?
Спасибо за статью! Traits реально очень сильная штука, часто наследование применять не-хотелось для небольшого общего функционала, Traits в таких случаях самый раз.
Есть еще одно популярное разночтение. Очень многие под View подразумевают лишь шаблонизатор и вызывают его прямо из контроллера, в то время как есть и иной взгляд — что View лишь представляет полученные от контроллера данные в понятный для шаблонизатора вид, попутно дополняя их данными, не зависящими от текщего пользовательского ввода (например строчку с информацией об авторизованном пользователе).
Поэтому при каждом шевелении в пользовательском интерфейсе, управление попадает в контроллер.
По-моему только так и должно быть. Каждому делу — своя группа классов. Лишь один компонент отвечает за обработку пользователького ввода — контроллер. Как исключения — случаи общей пре-обработки, вроде авторизации или выбора локали.
Полностью поддерживаю идею автора. Сам все больше и больше стал отходить от первичных ключей, ибо действительно — id часто не несет ничего в предметной области! В объектной модели это всегда воспринималось мной как «поле только для mysql». Самый частый кандидат на замену id у меня — url, например id бренда легко заменяет его url.
По-моему хорошее начинание — буквально на часик повесить такой пост, потом грохнуть его, решив свою проблему. Часто таким способом пользоваться конечно не стоит — но с другой стороны — часто ли люди меняют жилье?
По-моему только так и должно быть. Каждому делу — своя группа классов. Лишь один компонент отвечает за обработку пользователького ввода — контроллер. Как исключения — случаи общей пре-обработки, вроде авторизации или выбора локали.
Ей бы еще синхронизацию…
Я — за, чтобы такие темы были на хабре.