OnYourLips: Вообще есть две веские причины инджектить весь контейнер - до Symfony 2.3 как раз таки изза отсутствия ленивой инициализации сервисов, а до сих пор как средство разрешения циклических зависимостей. Последнее для контроллеров редкость, да и вообще лучше стараться избегать подобного. Но все же...
OnYourLips: плохой совет если речь идет о сервисах. В контроллерах норм, ибо не думаю что автор вопроса будет заботиться о таких вещах как ленивая инициализация сервисов и т.д. А контроллеры как сервисы это вообще отдельная история. Не вижу в этом смысла так как переиспользовать контроллер все равно не выйдет, и если делать их тонкими в этом нет особо смысла.
vasIvas: а я не против поболтать) Только согласен не сейчас и не здесь.
Просто почти все фреймворки - MVC. В документации к той же симфони говорится (я чуть перефразировал) о том что "да, можно назвать его MVC но нам больше по душе request-response фреймворк, а что и как внутри решайте сами, разделение бизнес логики и логики представления мы предоставим из коробки но все в ваших руках"
В СНГ - без понятия, не могу предоставить такую статистику. Но уверен, вам точно хватит.
mamkaololosha, вы о чем вообще? Я не вижу связи с вопросом.
По сути, все фундаментальные вещи и принципы были есть и будут всегда (во всяком случае ближайшее время). Не обязательно знать как именно микропрограммы хранятся в ПЗУ процессора, нужно понимать что они там таки как-то хранятся и как-то управляют всем этим чудом. Важно понимать зачем нужен кэш процессора, о том что скрывается за словами "конвеер", предсказание переходов....
В контексте того же GPU, если разработчик работает с графикой он просто обязан знать архитектуру современных GPU. Не на кровне системотехники и реализации в желехе, я хоты бы понимать как выполняется шейдерная программа, что такое варп (в контексте CUDA), почему нужно работать не с глобальной памятью а стараться данные переносить в шаред мемори, как можно ускорить программу за счет учета таких вещей как транзакции в памяти или там... не знаю... дивергенция нитей внутри одного варпа изза кучи лишних переходов.
Хз... Как по мне архитектуру знать нужно, базовые крипичики на которых все работает. Естественно что все знать не получится и следует выделять какой-то уровень абстракции дальше которого лесть не стоит ибо это излишняя информация.
Так могут подумать люди, которые:
- часто сталкиваются с ситуациями когда в имени добавляют код региона (например вы)
- люди живущие в 24-ом регионе (и я уверен что большинство из них не знает что у них регион такой номер имеет а еще больший процент и смотреть даже не будет на доменное имя).
lega: Ну если не придираться к терминологии и реализации, если брать в расчет по большей части стиль написания кода и то, как это все работает, то в общем и целом да.
Но проблем от этого не меньше. С нодой все хорошо ровно тогда, когда блоки задач в очереди маленькие. А если там периодически возникают жирные штуки с циклами и т.д. то начинаются проблемы. И их приходится решать... и решать их на ноде не сильно удобно.
Максим: ну так это относится к логике представления, то есть мы ловим ивент DOM-а и вызываем метод контроллера. Все хорошо. Другое дело если у директивы будет еще какая-то внутренняя логика по работе с данными.
Сразу скажу что все что косается непосредственно загрузки файла стоит вынести в сервис. Таким образом мы уменьшим код директивы существенно и сможем реюзать эту логику где-то еще.
Ну и стоит заметить что добавление 25-ого кадра не увеличивает FPS. Это дополнительный видеоряд между кадрами которого основной. Крутить такое видео могут как с 24fps так и с любым другим.
