То, что вы описали, часто используется в компонентах Joomla например
Компонент должен работать и в 1.5 и в 2.5, но в 2.5 удалили функцию, которая была в 1.5 или ее переименовали, и она используется в этом компоненте
Для этого и пишутся там такие хаки, которые по требованию создают нужную функцию
Ничего в этом хорошего нет, но это ведь legacy code :)
Статья очень интересная, спасибо!
Мне кажется ваша модель имеет 1 очень большой плюс — она более гибкая. Мне кажется, похожую модель можно использовать для таргетированной/контекстной рекламы
Спасибо за статью, жаль ее не было, когда я так в ней нуждался :)
Как раз недавно делал аналитику и БД была Cassandra
Вкратце — задача была хранить логи действий пользователей в системе и потом на основе этих данных выводить статистику
Так вот
1) действительно столкнулся с проблемой каунтеров (но без них тяжеловато было бы вести подсчет)
2) данные действительно очень денормализуются, вместо 1 коассической реляционной таблицы получилось 12 «кассандровских»
Правда потом уменьшилось до 4, так как часть работы по аггрегации данных вынеслась в логику приложения
В остальном пока все отлично, вставка действительно очень быстрая, выборка при правильно аггрегированных данных тоже работает хорошо
фреймворки, в том числе и микро, очень спорная тема — вот например зачем брать микрофреймворк и перелапачивать его под свои нужды, а не просто взять нужные библиотеки и использовать их?
Ну ок, Silex — Symfony/routing — Pimple + php-di + FastRoute. Согласитесь — это уже не Silex.
зачем одновременно Pimple + php-di?
в silex к слову Pimple используется, другое дело если вы его на php-di поменять хотите
для laravel использовался opcache? пробовали nginx+fpm?
просто что-то мне подсказывает, что вовсе не в laravel может быть дело, но я могу ошибаться — не видел проектов
1. Если человек захочет посмотреть исходный код страницы (не через firebug, а в отдельном окне), то при загрузке с генерируется новый токен, и вернувшись на страницу ни один запрос не будет обработан. Возможно это и хорошо, нечего лезть в исходный код.
да я думаю просто, если пользователь откроет ту же (а может даже и любую) страницу вашего приложения в новом табе, то в старом табе уже AJAX запросы работать не будут, верно?
для Yii не смотрел честно говоря, но для Symfony 2 есть плагин, который распознает все сервисы, прописанные в конфигах, даёт ьыстрый способ навигации по сервисам и естественно type hinting отлично работает.
думаю в ближайшее время, что-нибудь такое должно и для Yii 2 появится
описание зависимостей в конфигурационном файле не является целью инверсии управления
её цель — создание гибкого слабосвязанного кода, который позволит строить расширяемую модульную систему. ещё лучше, чтобы при этом зависимости могли конфигурироваться динамически.
как они будут конфигурироваться — конфиг-файл, параметры из администраторской панели, данные с какого-либо устройства, да что угодно — это специфика приложения
с Magento честно говоря не работал, но PHP DI действительно отличный контейнер, который удобно добавлять в существующий проект либо при написании проекта на фреймворке, в котором проблема внедрения зависимости не решается из коробки.
в Symfony 2 мне прекрасно хватает их коробочного решения :)
я соглашусь с Вами, что такой вариант сделает 2 модуля действительно не зависимыми друг от друга, но как Вы сами сказали — отлаживать код тяжело, да и понятность кода резко упадёт.
я бы observer (не считая классического случая использования) использовал в случае реализации Event Sourcing — тогда действительно это имело бы место и смотрелось гармонично, остальные варианты мне кажется не очень себя оправдывают
Компонент должен работать и в 1.5 и в 2.5, но в 2.5 удалили функцию, которая была в 1.5 или ее переименовали, и она используется в этом компоненте
Для этого и пишутся там такие хаки, которые по требованию создают нужную функцию
Ничего в этом хорошего нет, но это ведь legacy code :)
Мне кажется ваша модель имеет 1 очень большой плюс — она более гибкая. Мне кажется, похожую модель можно использовать для таргетированной/контекстной рекламы
Как раз недавно делал аналитику и БД была Cassandra
Вкратце — задача была хранить логи действий пользователей в системе и потом на основе этих данных выводить статистику
Так вот
1) действительно столкнулся с проблемой каунтеров (но без них тяжеловато было бы вести подсчет)
2) данные действительно очень денормализуются, вместо 1 коассической реляционной таблицы получилось 12 «кассандровских»
Правда потом уменьшилось до 4, так как часть работы по аггрегации данных вынеслась в логику приложения
В остальном пока все отлично, вставка действительно очень быстрая, выборка при правильно аггрегированных данных тоже работает хорошо
зачем одновременно Pimple + php-di?
в silex к слову Pimple используется, другое дело если вы его на php-di поменять хотите
просто что-то мне подсказывает, что вовсе не в laravel может быть дело, но я могу ошибаться — не видел проектов
И второе — HttpKernel + HttpFoundation это ли не Silex?
да я думаю просто, если пользователь откроет ту же (а может даже и любую) страницу вашего приложения в новом табе, то в старом табе уже AJAX запросы работать не будут, верно?
думаю в ближайшее время, что-нибудь такое должно и для Yii 2 появится
её цель — создание гибкого слабосвязанного кода, который позволит строить расширяемую модульную систему. ещё лучше, чтобы при этом зависимости могли конфигурироваться динамически.
как они будут конфигурироваться — конфиг-файл, параметры из администраторской панели, данные с какого-либо устройства, да что угодно — это специфика приложения
в Symfony 2 мне прекрасно хватает их коробочного решения :)
я бы observer (не считая классического случая использования) использовал в случае реализации Event Sourcing — тогда действительно это имело бы место и смотрелось гармонично, остальные варианты мне кажется не очень себя оправдывают