значит повезло :) на билде — 7.1.12 (релиз от 29.11.17) с обвязкой кеширования под memcache работает не очень. В прочем на это особо внимание не акцентируется, мне больше хочется стоящий релиз альто, чтобы не было проблем реализации которые есть сейчас :)
Сначала отвечу про php7 — у меня сейчас несколько проектов работает на текущей версии Альто в конфигурации nginx+php7. Для новой версии минимум php 5.6 значится не потому, что под семеркой не будет работать, а просто потому, что фичи семерки в ней не используются. Но сам код отлично крутится под php7.
У меня имеется проект на альто под php 7.1 и работает он весьма плачевно, пришлось достаточно сильно изменить конфигурацию, а так же решить вопрос с полифилом под mbstring библиотеку. Главная страница админки с тестированием под php 7.1 даже не отображается, работает только левое меню и остальные функции.
Синглтон по своей парадигме уже является антипаттерном ввиду того, что статическое обращение к объекту весьма дорогая операция в идиологии php.
Обращение к фасадам через контейнер удешевляет данную операцию, т.к. интерпретатору не нужно постоянно объявлять объект глобально, он использует уже инициализированный объект в рамках вышеназванного контейнера.
Так что если вдруг сложилось впечатление, что я не знаю современных движков — это не так. ))) Знаю, пробую на практике, смотрю, что хорошего можно из них взять в Альто.
Ни в коем случае, темболее что, симфония и слим это не движки)
Сейчас в Альто 4 класса паттерна Singleton — Application, Router, Engine, Storage (с наследником Config).
Насчет синглтона понятия давно размытые, но я привык считать его антипаттерном из-за того, что еще со времен пхп 4, когда этот паттерн стал чертовский модным, многие люди не правильно поняли парадигму SOLID, а конкретно «Single Responsibility Principle». Паттерн синглтона очень скверный и сложный в реализации правильно, он усложняет юнит тестирование, лишает смысла «принцип единой ответсвенности» ввиду того, что он обязан следить за самим объектом синглтона, а так же за тем за чем он реализован — это и принцип единой ответсвенности разные вещи.
Проблема паттерна продолжается в том, что при обычных его реализациях обратится к «переиспользованию» объекта не реально. Именно потому нам на помощь приходят фасады и контейнер — фасад это структурный паттерн, он позволяет скрыть сложность системы путём сведения всех возможных внешних вызовов к одному объекту, делегирующему их соответствующим объектам. А контейнер позволяет отслеживать состояние объекта, в том числе проверять единственный экземпляр был инициализирован или нет, а темболее не мешает переиспользовать объект еще раз создавая его новые экземпляры под конкретные нужды.
Я не говорю про проблему синглтона с работой зависимостей с ним достаточно сложно работать, так же достаточно сложно следить за ним состояние объекта при необходимости работы одного объекта в нескольких потоках. К примеру JVM не позволяет проверить существует ли один экземпляр объекта в пространстве, он всего-лишь проверяет существует ли экземпляр объекта в текущем загрузчике, однако сложные проекты на java пишутся с использованием более одного загрузчика. (это для примера минуса синглтона)
В репозитории я заметил именно синглтон объекты Application, Engine, PluginManager, Router, Storage, HookManager — тестирование этих объектов очень усложнено, изолировать их методы между собой весьма сложно.
На мой взгляд на текущий момент лучше пойти с использованием паттерна DI, в том числе внедряя сервис-провайдеры, которые позволят построить как структурное приложение (Приложение —> События —> Роутер —> Модули —> Ответ), так и внедрить модульную систему, где каждый модуль сможет иметь свой сервис провайдер, а так же сможет влиять на всю систему целиком сразу после установки модуля, без необходимости писать инструкции по изменению кода (пример системы octobercms, система после установки плагина в том числе расширяет модели других объектов/системы, при этом не влияя на основную логику расширяемой модели)
aVadim почему юзается все тот же забитый паттерн Singlton, который уже является антипатерном в тенденции текущего статуса php. Так же по текущей тенденции все системы и проекты стараются начать плавный переход на php7, который показывает весьма более приятные результаты как по скорости, так и по возможностям разработки и оптимизации.
В системе создается свой велосипед, как вариант существуют микрофреймворки simfony 4, slim framework, на случай если нет конкретного желания тянуть laravel с его не слабой абстракцией. Указанные фреймворки поддерживают систему адаптеров(кеширование, бд), совместимость с PSR-7, так же Роутинг.
Мое личное суждение, не пинайте. Сам пользуюсь альто, нет желания чтобы система ушла как LiveStreet с его мусором и дырками, а так же весьма сложной поддержкой со временем.
А про подход с переходом?
Ведь сейчас вся вот эта «канитель» будет как клубок с нитками обрастать мусором в попытках привести все в порядок. Возможно проще начать новую ветку модулей и плагинов, где можно будет писать модуль в нормальном синтаксисе. Конечно для этого понадобится прослойка, но то, что сейчас творится в модулях это сущий ад...
Если быть точнее, я предлагаю не исправлять текущий подход в работе с БД, а начать искоренять зло начиная с корня. Таким образом и совместимость с текущими модулями останеться и можно будет создать новую ветку модулей с нормальным исправленным подходом и логикой.
Возможно узнать, почему выбор пал на реализацию все-таки своего AR, нежели взять готовый орм а-ля Doctrine, Eloquent?
Ведь в них можно передать текущий пул соединения и использовать в новой ветке модулей по примеру как это сделано у 1C-Bitrix, а именно Компоненты 1.0, Компоненты 2.0?
У меня имеется проект на альто под php 7.1 и работает он весьма плачевно, пришлось достаточно сильно изменить конфигурацию, а так же решить вопрос с полифилом под mbstring библиотеку. Главная страница админки с тестированием под php 7.1 даже не отображается, работает только левое меню и остальные функции.
Синглтон по своей парадигме уже является антипаттерном ввиду того, что статическое обращение к объекту весьма дорогая операция в идиологии php.
Обращение к фасадам через контейнер удешевляет данную операцию, т.к. интерпретатору не нужно постоянно объявлять объект глобально, он использует уже инициализированный объект в рамках вышеназванного контейнера.
Ни в коем случае, темболее что, симфония и слим это не движки)
Насчет синглтона понятия давно размытые, но я привык считать его антипаттерном из-за того, что еще со времен пхп 4, когда этот паттерн стал чертовский модным, многие люди не правильно поняли парадигму SOLID, а конкретно «Single Responsibility Principle». Паттерн синглтона очень скверный и сложный в реализации правильно, он усложняет юнит тестирование, лишает смысла «принцип единой ответсвенности» ввиду того, что он обязан следить за самим объектом синглтона, а так же за тем за чем он реализован — это и принцип единой ответсвенности разные вещи.
Проблема паттерна продолжается в том, что при обычных его реализациях обратится к «переиспользованию» объекта не реально. Именно потому нам на помощь приходят фасады и контейнер — фасад это структурный паттерн, он позволяет скрыть сложность системы путём сведения всех возможных внешних вызовов к одному объекту, делегирующему их соответствующим объектам. А контейнер позволяет отслеживать состояние объекта, в том числе проверять единственный экземпляр был инициализирован или нет, а темболее не мешает переиспользовать объект еще раз создавая его новые экземпляры под конкретные нужды.
Я не говорю про проблему синглтона с работой зависимостей с ним достаточно сложно работать, так же достаточно сложно следить за ним состояние объекта при необходимости работы одного объекта в нескольких потоках. К примеру JVM не позволяет проверить существует ли один экземпляр объекта в пространстве, он всего-лишь проверяет существует ли экземпляр объекта в текущем загрузчике, однако сложные проекты на java пишутся с использованием более одного загрузчика. (это для примера минуса синглтона)
В репозитории я заметил именно синглтон объекты Application, Engine, PluginManager, Router, Storage, HookManager — тестирование этих объектов очень усложнено, изолировать их методы между собой весьма сложно.
На мой взгляд на текущий момент лучше пойти с использованием паттерна DI, в том числе внедряя сервис-провайдеры, которые позволят построить как структурное приложение (Приложение —> События —> Роутер —> Модули —> Ответ), так и внедрить модульную систему, где каждый модуль сможет иметь свой сервис провайдер, а так же сможет влиять на всю систему целиком сразу после установки модуля, без необходимости писать инструкции по изменению кода (пример системы octobercms, система после установки плагина в том числе расширяет модели других объектов/системы, при этом не влияя на основную логику расширяемой модели)
В системе создается свой велосипед, как вариант существуют микрофреймворки simfony 4, slim framework, на случай если нет конкретного желания тянуть laravel с его не слабой абстракцией. Указанные фреймворки поддерживают систему адаптеров(кеширование, бд), совместимость с PSR-7, так же Роутинг.
Мое личное суждение, не пинайте. Сам пользуюсь альто, нет желания чтобы система ушла как LiveStreet с его мусором и дырками, а так же весьма сложной поддержкой со временем.
Ведь сейчас вся вот эта «канитель» будет как клубок с нитками обрастать мусором в попытках привести все в порядок. Возможно проще начать новую ветку модулей и плагинов, где можно будет писать модуль в нормальном синтаксисе. Конечно для этого понадобится прослойка, но то, что сейчас творится в модулях это сущий ад...
Если быть точнее, я предлагаю не исправлять текущий подход в работе с БД, а начать искоренять зло начиная с корня. Таким образом и совместимость с текущими модулями останеться и можно будет создать новую ветку модулей с нормальным исправленным подходом и логикой.
Возможно узнать, почему выбор пал на реализацию все-таки своего AR, нежели взять готовый орм а-ля Doctrine, Eloquent?
Ведь в них можно передать текущий пул соединения и использовать в новой ветке модулей по примеру как это сделано у 1C-Bitrix, а именно Компоненты 1.0, Компоненты 2.0?