Но проблема освещена с неверного угла.
В вебе существует сервер и множество параллельных клиентов. Они дерутся за ресурсы.
Чтобы данные были согласованы при параллельном доступе необходимо транзакции.
Существуют 2 типа транзакций: системные транзакции(БД, API, etc) и бизнес транзакции.
В большинстве случаев хватает 1 системной транзакции на 1 запрос клиента. Иногда в запросе может быть несколько транзакций.
Но большинство проблем начинается тогда, когда необходима 1 транзакция на несколько запросов.
В данном случае на 1 бизнес транзакцию приходится несколько запросов и соответственно несколько системных транзакций.
На помощь приходят паттерны Optimistic Offline Lock и Pessimictic Offline Lock.
Первый паттерн великолепно реализован в PHP Doctrine 2(смотрите в документации Doctrine 2 ORM 2 documentation — 13.2.1. Optimistic Locking).
Необходимость второго паттерна возникает редко. Когда возникает — реализую в минимально простом виде(в двух словах паттерн не описать, погуглите).
Т.е. в общем и целом всё отлично в PHP с параллелизмом!
Он предоставляет интерфейсы, которые должны реализовать фреймворки.
Т.е. ещё одна зависимость в композере от пакета php-fig/http-message
Итак уже в папке vendor множество всяких пакетов… И тут будет ещё один.
Для чего это? Чтобы облегчить перевод приложения из одного фреймворка в другой?
Фреймворки должны реализовать группу интерфейсов PSR-7, но никто не мешает авторам фреймворков добавить собственные методы. Это не нарушает принципы ООП. А эти методы могут быть очень полезными.
Т.е. встаёт выбор, использовать интерфейс PSR-7, и иметь независимость от фреймворка.
Или использовать интерфейс фреймворка(который также реализует PSR-7), но. получить зависимость от фреймворка и удобные методы.
Я выберу второе.
Имхо, единственный и главный плюс этого стандартна, когда программируешь на одном фрейморке, потом вдруг понадобилось использовать другой — а ты уже знаешь, как обращаться с http компонентом.
Но тут IDE намного больше пользы принесет.
Но проблема освещена с неверного угла.
В вебе существует сервер и множество параллельных клиентов. Они дерутся за ресурсы.
Чтобы данные были согласованы при параллельном доступе необходимо транзакции.
Существуют 2 типа транзакций: системные транзакции(БД, API, etc) и бизнес транзакции.
В большинстве случаев хватает 1 системной транзакции на 1 запрос клиента. Иногда в запросе может быть несколько транзакций.
Но большинство проблем начинается тогда, когда необходима 1 транзакция на несколько запросов.
В данном случае на 1 бизнес транзакцию приходится несколько запросов и соответственно несколько системных транзакций.
На помощь приходят паттерны Optimistic Offline Lock и Pessimictic Offline Lock.
Первый паттерн великолепно реализован в PHP Doctrine 2(смотрите в документации Doctrine 2 ORM 2 documentation — 13.2.1. Optimistic Locking).
Необходимость второго паттерна возникает редко. Когда возникает — реализую в минимально простом виде(в двух словах паттерн не описать, погуглите).
Т.е. в общем и целом всё отлично в PHP с параллелизмом!
Он предоставляет интерфейсы, которые должны реализовать фреймворки.
Т.е. ещё одна зависимость в композере от пакета php-fig/http-message
Итак уже в папке vendor множество всяких пакетов… И тут будет ещё один.
Для чего это? Чтобы облегчить перевод приложения из одного фреймворка в другой?
Фреймворки должны реализовать группу интерфейсов PSR-7, но никто не мешает авторам фреймворков добавить собственные методы. Это не нарушает принципы ООП. А эти методы могут быть очень полезными.
Т.е. встаёт выбор, использовать интерфейс PSR-7, и иметь независимость от фреймворка.
Или использовать интерфейс фреймворка(который также реализует PSR-7), но. получить зависимость от фреймворка и удобные методы.
Я выберу второе.
Имхо, единственный и главный плюс этого стандартна, когда программируешь на одном фрейморке, потом вдруг понадобилось использовать другой — а ты уже знаешь, как обращаться с http компонентом.
Но тут IDE намного больше пользы принесет.
Серьёзно, в чём плюс этого PSR-7?