корректная "последовательность" ивентов же составляет консистентность приложения

ну ты опять про асинхронность

зачем ты это мешаешь с ивентами и IoC неясно

потому что у вас так было сделано и ты страдал?

ну у всех так сделано

есть примеры другого подхода?

симфонишные\спринговые контроллеры - пример IoC

нормальный другой подход без ивентов, просто с вызовами методов

так там же ивенты сплошные)

именно как раз из-за того, что он реализается в основном через ивенты, а ивенты это жопа

ивенты это хорошо, просто ими надо уметь пользоваться

так там же ивенты сплошные)

ты можешь сделать дамми диспатчер, а контроллеры все равно работать будут)

и ивенты там - благо, почти мана небесная

есть примеры другого подхода?

Callbacks, scheduler, template method?

это же все про ивенты :)

что такое ивенты?

это же все про ивенты :)

Эээ, где в шаблоном методе ивент? Очередность вызова метода? о.О

ок, поясню: есть синхронный флоу, это например мы получили реквест интерпретируя его как RPC, зароутили его на определенный контроллер, вызвали и вернули результат

но синхронный флоу нам не интересен, мы хотим реюзать код

реюзать код никто не хочет

все хотят реюзать абстракции)

абстракции это тоже код

и синхронный флоу никакого влияния на реюз не оказывает, либо опять же мы о чем-то очень разном

абстракции для того и придуманы, чтоб их реюзать

так вот, с синхронным флоу понятно? тут чистый IoC как процедурный подход

что значит “чистый IoC как процедурный подход”?

внезапно, добавим асинхронности

ну в википедию глянь, что-ли)

там как раз кейсы описаны

к примеру мы хотим писать логи в контроллере

чот мы можем сделать, чтоб не нарушить IoC?

чот мы можем сделать, чтоб не нарушить IoC?

Di?

но мы же тогда явно будем дёргать функционал другого модуля

а по идеологии IoC мы можем только с фреймворком общаться

а по идеологии IoC мы можем только с фреймворком общаться

Ладно, сдаюсь, говори, что в твоей голове:)

да я ж уже все сказал: мы шлем ивент для фреймворка ака "залогируйте мне вот это пожалуйста" :)

этим мы не нарушим IoC

ну в википедию глянь, что-ли)

ну в википедии нет никаких “чистых IoC как процедурного подхода”

этим мы не нарушим IoC

нарушение такое же как с вызовом метода

почему? мы же не вызываем никакой метод, это не контрол флоу

Похоже я не могу уловить мысль...

почему? мы же не вызываем никакой метод, это не контрол флоу

как ты ивент бросаешь?

Наброшу: окей, AOP будет нарушать IoC в вашем представлении?

грубо говоря типа так: application.dispatch('my_event')

явный вызов есть, за ним следуют действия

control flow полностью соответстует тому, как ты вызываешь методы

нет никакой инверсии

AoP может и нарушать, почему нет?

да я ж уже все сказал: мы шлем ивент для фреймворка ака "залогируйте мне вот это пожалуйста" :)

С помощью чего ты бросишь ивент в контроллере? С помощью диспетчера? А диспетчер от куда ты возьмёшь ?

методы, процедуры и другие штуки - это конкретные реализации конкретных языков

а контрол флоу - это понятие абстрактное

это когда твой модуль каким-то образом влияет на работу приложения напрямую, контролируя это

control - контролировать

что тут не ясно же?

Ну т.е. в вашем примере если мы сделаем аспект для логирования и будет в котроллере висеть поинт на него это нарушение, а ивент нет? Моя не понимать

я ваще перестал понимать, что тут обсуждается

я ваще перестал понимать, что тут обсуждается

Как логировать контроллеры:)

С помощью чего ты бросишь ивент в контроллере? С помощью диспетчера? А диспетчер от куда ты возьмёшь ?

диспетчер можно себе представить как реализацию асинхронного возвращения результата работы контроллера

а не как продолжение флоу

диспетчер можно себе представить как реализацию асинхронного возвращения результата работы контроллера

Нет, все равно не понятно

также можно представить и любой вызов метода

короч ладно, я все)

диспетчер можно себе представить как реализацию асинхронного возвращения результата работы контроллера

Давай пример с кодом, а не рассуждение о картине Репина:)

чуть позже, надо уехать срочно

чуть позже, надо уехать срочно

Жду ответа, как соловей лета:)

я тут, ща вам обьясню на пальцах

ERROR: S client not available

почему DI не решает задачу IoC очень просто можно понять на примере внешнего вызова сервиса, который может упасть

у нас например кейс логировать действия юзера, для аналитики

если этот сервис, скажем, заинжектить в контроллер, а потом вызвать, то надо заворачивать в try-catch

потому что вызов не критичен для логики работы и не должен ронять приложение

вот вам на лицо нарушение ioc

с другой стороны, если мы бросим ивент для обработки ферймворком, и пусть сам фреймворк решает как его обрабатывать и в каком модуле - то нарушение ioc не будет. мы можем абстрагироваться от того, что бросить ивент - это просто еще один способ вернуть результат работы контроллера, кусками так сказать

по поводу аспектов: они тут могут порешать если мы сможем заменить вызов логирования поинтами и инкапсулировать логику обработки исключений, но суть не особо поменяется, будет работать в точности как с ивентами

с другой стороны, если мы бросим ивент для обработки ферймворком, и пусть сам фреймворк решает как его обрабатывать и в каком модуле - то нарушение ioc не будет. мы можем абстрагироваться от того, что бросить ивент - это просто еще один способ вернуть результат работы контроллера, кусками так сказать

ты можешь завести интерфейс логгера, который не бросает исключения

а так, твой фреймворк может кинуть эксепшн

или там диспатчер

тут же вопрос кто владеет интерфейсом

если этот safe-интерфейс живет в фреймворке, то это надо для каждого внешнего вызова такое создаавать, и декорировать там, и.т.д, очень много бойлерплейта

а диспатчер если накрылся - то это фреймворк накрылся, можно падать)

но я хз как реализовать диспатчер, чтоб он падал

Всем привет. А никто не кинет статьей на Хабре про проектирование рест апи? Там ещё запуск ракеты был в примерах. Давно смотрел, сейчас хочу перечитать, но не нашел сходу

Кто тут спец по английским терминам? "Атомарная операция" как Linearizability это норм? https://en.wikipedia.org/wiki/Linearizability

во-первых (не вчитывался еще) linearizability - это свойство то есть, это может быть "атомарность"

тут же вопрос кто владеет интерфейсом

мы про DI или про DIP?

Всем привет. А никто не кинет статьей на Хабре про проектирование рест апи? Там ещё запуск ракеты был в примерах. Давно смотрел, сейчас хочу перечитать, но не нашел сходу

rest api не бывает. А так - почитай что такое идемпотентность, какие http verbs обязаны быть идемпотентными, ну а дальше смотри какие-нибудь стандарты вроде json api для примера форматов респонсов. Ну или не заморачивайся и делай тупо http api так как тебе удобно. Или вообще graphql бери

Все конечно хорошо, но я вроде задал вполне конкретный вопрос - не смог найти статейку. Я же не уточнял что именно ищу в ней

Все конечно хорошо, но я вроде задал вполне конкретный вопрос - не смог найти статейку. Я же не уточнял что именно ищу в ней

хз про какую ты статью, я лишь хочу тебе сказать что rest api это миф

и лучше разобраться с тем что такое идемпотентность и как она аффектит клиент

окей

мы про DI или про DIP?

Пардон. Я имел ввиду декоратор. Ну как "safe-интерфейс" не в смысле интерфейса

> Или вообще graphql бери jsonrpc

> Или вообще graphql бери jsonrpc

graphql прикольнее

не могу не согласиться. Но в большинстве случаев его комплексность избыточна :)

Всем привет. А никто не кинет статьей на Хабре про проектирование рест апи? Там ещё запуск ракеты был в примерах. Давно смотрел, сейчас хочу перечитать, но не нашел сходу

http://bfy.tw/FWDn

Если бы гуглом нашел - тут не спрашивал)

первая же ссылка