Без сравнение показать "почему логика в сервисах является более правильным подходом", мне кажется, невозможно. У вас в голове есть некоторая реализация Rich Domain Model к которой вы апеллируете, но у тех кто читает статью, этой реализации нет, поэтому статья кажется неполной
По поводу MethodSpecCollection и инициализации при каждом запросе
Речь не про компиляцию, а рантайм. Условно в вашем случае результирующий код будет такой:
$collection = new MethodSpecCollection();
$collection->addMethodSpec('foo', $container->get(FooMethod::class));
$collection->addMethodSpec('bar', $container->get(BarMethod::class));
// И так 100500 раз
В итоге коллекция будет хранить все инстансы, при том что в один момент времени они нам все не понадобятся.
В случае в локатором будет что-то вроде:
$serviceLocator = new ServiceLocator();
$serviceLocator->addMethodSpec('foo', fn () => $container->get(FooMethod::class));
$serviceLocator->addMethodSpec('bar', fn () => $container->get(BarMethod::class));
// И так 100500 раз
И в файлике config/services.yaml в секцию services добавить раздел с той папкой, которая предполагается для реализации всех ваших дальнейших методов API.
Лишний шаг, т.к. у вас все равно на эти методы навешиваются аттрибуты. В OVJsonRPCAPIBundle::build можно сделать что-то вроде
Я бы предпочел чтобы шаблонизатор мне сообщал об необъявленной пременной, в противном случае опечатаетесь в каком-нибудь флаге, и он у вас навсегда false, и сообщит вам об этом только клиент
Формирование тела запроса мы от туда убрали, т.к. тело запроса зависит от отправителя. Остается подготовка данных. В чем она заключается? Срендерить шаблон и передать туда переменные? Ну я бы это тоже через отдельный сервис сделал, чтобы не зависеть от шаблонизатора.
Мне кажется это обычный дата-класс (его даже абстрактным делать не надо, чтобы можно было отправлять простые письма)
Ссылка ведет на статью про сервис локатор (который собственно и создан для того чтобы find the service) + он таки ищет этот сервис с помощью Yii::$container. Это ли не оно?
Ну и вы просто вдумайтесь, какого будет потом дебажить такой код. Ни намека на то, чем является $this->mailer
Если в проекте подключен symfony/serializer, то будет работать из коробки
composer create-project symfony/skeleton symfony-accept-format
cd symfony-accept-format
composer req serializer
GET http://127.0.0.1:8880/
Accept: application/json
#{
# "type": "https:\/\/tools.ietf.org\/html\/rfc2616#section-10",
# "title": "An error occurred",
# "status": 500,
# "detail": "Internal Server Error"
#}
###
GET http://127.0.0.1:8880/
Accept: text/html
###
#<body>
#<div class="container">
# <h1>Oops! An Error Occurred</h1>
# <h2>The server returned a "500 Internal Server Error".</h2>
#
# <p>
# Something is broken. Please let us know what you were doing when this error occurred.
# We will fix it as soon as possible. Sorry for any inconvenience caused.
# </p>
#</div>
#</body>
#</html>
Там дальше по тексту отдельно упоминается service locator
Because the client does not build or find the service itself, it typically only needs to declare the interfaces of the services it uses, rather than their concrete implementations.
Мне кажется, вы отбрасываете саму игровую логику, которая и будет бутылочным горлышком. Я бы сначала сделал игру, со всеми фичами, которые хочу видеть. И уже на ней бы экспериментировал с технологиями
При этом, надо сказать, что лично у меня сложилось ощущение, что BrowserQuest сильно выигрывает у вашего Игоря по отзывчивости (и там и там было по одному игроку).
Вам нужно сделать что-то аналогичное, потому что техническая демка - это не то, чем нужно заманивать, а вот на BrowserQuest я залип надолго (и соответственно тыкался в ней минут 30, в отличие от вашей игры, где меня хватило на пару минут)
Без сравнение показать "почему логика в сервисах является более правильным подходом", мне кажется, невозможно. У вас в голове есть некоторая реализация Rich Domain Model к которой вы апеллируете, но у тех кто читает статью, этой реализации нет, поэтому статья кажется неполной
Было бы круто увидеть реализацию с Rich Domain Model
К примеру вот: https://github.com/symfony/symfony/discussions/46789
Речь не про компиляцию, а рантайм. Условно в вашем случае результирующий код будет такой:
В итоге коллекция будет хранить все инстансы, при том что в один момент времени они нам все не понадобятся.
В случае в локатором будет что-то вроде:
т.о. они будут отрезолвлены в методе get
Лишний шаг, т.к. у вас все равно на эти методы навешиваются аттрибуты. В
OVJsonRPCAPIBundle::build
можно сделать что-то вродеMethodSpecCollection
в идеале заменить наServiceLocator
, чтобы не инициализировать все методы при каждом запросеP.S. Почему выбрали gitflic в качестве хранилища? У меня он
composer.json
как-то странно рендерит.Можно обойтись без бандлов: https://gist.github.com/BoShurik/009cdeef1fb7a43fc1856feaaf317062
Рекомендую Return of the Obra Din от создателя Papers, Please. Судя по всему опять создана в одиночку
Я бы предпочел чтобы шаблонизатор мне сообщал об необъявленной пременной, в противном случае опечатаетесь в каком-нибудь флаге, и он у вас навсегда false, и сообщит вам об этом только клиент
Да, так нельзя, но нас спасают статические анализаторы:
https://psalm.dev/r/658910a73a
Формирование тела запроса мы от туда убрали, т.к. тело запроса зависит от отправителя. Остается подготовка данных. В чем она заключается? Срендерить шаблон и передать туда переменные? Ну я бы это тоже через отдельный сервис сделал, чтобы не зависеть от шаблонизатора.
Мне кажется это обычный дата-класс (его даже абстрактным делать не надо, чтобы можно было отправлять простые письма)
А что в нем? Если убрать отправку письма в отдельный сервис, то что в нем остается?
Позволяет
Как бонус:
Ссылка ведет на статью про сервис локатор (который собственно и создан для того чтобы find the service) + он таки ищет этот сервис с помощью
Yii::$container
. Это ли не оно?Ну и вы просто вдумайтесь, какого будет потом дебажить такой код. Ни намека на то, чем является
$this->mailer
Если в проекте подключен
symfony/serializer
, то будет работать из коробкиВот на php: symfony/mailer
Там дальше по тексту отдельно упоминается service locator
Мне кажется, вы отбрасываете саму игровую логику, которая и будет бутылочным горлышком. Я бы сначала сделал игру, со всеми фичами, которые хочу видеть. И уже на ней бы экспериментировал с технологиями
Ну, кстати, из этого FAQ видно, что для вашей целевой аудитории не особо важно количество игроков онлайн
Откуда желание повысить онлайн? Это какой-то запрос от реальных разработчиков игр? Или просто цель с потолка?
При этом, надо сказать, что лично у меня сложилось ощущение, что BrowserQuest сильно выигрывает у вашего Игоря по отзывчивости (и там и там было по одному игроку).
Вам нужно сделать что-то аналогичное, потому что техническая демка - это не то, чем нужно заманивать, а вот на BrowserQuest я залип надолго (и соответственно тыкался в ней минут 30, в отличие от вашей игры, где меня хватило на пару минут)