DT
Size: a a a
2020 September 24
SB
Vlad Sobenko
Бывает офк. Они и есть. Но чтобы юзать DI нормальн, нужно чтобы стейта не было.
так а зачем вы DI тогда приплетаете к разговору о сервисах?
И DI умеет каждый раз новый обект выдавать если что
И DI умеет каждый раз новый обект выдавать если что
VM
ага, только каждый раз нужно пробрасывать ему юзер агента отдельно, а если юзать это дело где-то внутри глубоко, то туда придется дополнительно пробрасывать юзерагента, а не просто либу
сделай простую структурку с результатом, задекти девайс на входе в приложение и дальше прокидывай результат, а не либку
SB
А вы можете написать как вы их понимаете? своими словами
признаки сервиса для вас
признаки сервиса для вас
D
Volodymyr Melko
сделай простую структурку с результатом, задекти девайс на входе в приложение и дальше прокидывай результат, а не либку
можно и так. я лично не вижу большой проблемы в самой либе, она заточена под детект одного юзер агента, вам надо в цикле без создания нового обьекта ? форкните и потом сделайте пул риквест
VS
так а зачем вы DI тогда приплетаете к разговору о сервисах?
И DI умеет каждый раз новый обект выдавать если что
И DI умеет каждый раз новый обект выдавать если что
Всю цепочку тоже придётся так сконфигурировать тогда. Т.е. все другие сервисы, которые используют этот должны будут создаваться каждый раз.
k
так а почему нам в одном случае важно чтобы зависимость светилась в конструкторе а в другом нормально когда она внутри вылезает?
потому что можно создать зависимость, которая в конструкторе, раньше. Т.к. раньше известно как её создать.
Дальше вопрос - почему важно создать зависимость пораньше
Дальше вопрос - почему важно создать зависимость пораньше
SB
потому что можно создать зависимость, которая в конструкторе, раньше. Т.к. раньше известно как её создать.
Дальше вопрос - почему важно создать зависимость пораньше
Дальше вопрос - почему важно создать зависимость пораньше
а для меня важно чтобы я мог заменить зависимость без изменния потребитиля оной зависимости
VM
а для меня важно чтобы я мог заменить зависимость без изменния потребитиля оной зависимости
адски плюсую
ПГ
Прерву:) Хэлпаните плиз, чет не могу понять херня или нет:
Берем кейс редактирования с помощью формы. Редактирование не всей сущности. Из базы тянем только нужные данные, мапип на readmodel.
Страница редактирования: есть форма, чтобы ее заполнить, создаем ее на основе readmodel из базы
Экшен редактирования: для редактирования используется command который заполняется формой.
В итоге идентичные readmodel и command, плюс такие же поля в форме. В итоге при добавлении свойства в этот экшен придется менять практически 3 идентифичных файла. Особенно напрягает 1 в 1 readmodel и command. Что тут не так или это норм?
Берем кейс редактирования с помощью формы. Редактирование не всей сущности. Из базы тянем только нужные данные, мапип на readmodel.
Страница редактирования: есть форма, чтобы ее заполнить, создаем ее на основе readmodel из базы
Экшен редактирования: для редактирования используется command который заполняется формой.
В итоге идентичные readmodel и command, плюс такие же поля в форме. В итоге при добавлении свойства в этот экшен придется менять практически 3 идентифичных файла. Особенно напрягает 1 в 1 readmodel и command. Что тут не так или это норм?
SB
Vlad Sobenko
Всю цепочку тоже придётся так сконфигурировать тогда. Т.е. все другие сервисы, которые используют этот должны будут создаваться каждый раз.
так зачем вы опять приплетаете техническую строну имплементации чего бы то ни было. Что такое сервис то для вас в нашем контексте?
k
а для меня важно чтобы я мог заменить зависимость без изменния потребитиля оной зависимости
тогда почему это неважно в случае с VO ?
VS
так зачем вы опять приплетаете техническую строну имплементации чего бы то ни было. Что такое сервис то для вас в нашем контексте?
Хз сервис для меня бесполезное понятие. Ибо все обьекты - что то делают.
SB
тогда почему это неважно в случае с VO ?
Почему не важно
Иногда важно
Например в доктрине мы передаем название класса конекшена в итоге бы можем менять зависимость пусть эта зависимость и есть VO
Иногда важно
Например в доктрине мы передаем название класса конекшена в итоге бы можем менять зависимость пусть эта зависимость и есть VO
VK
Прерву:) Хэлпаните плиз, чет не могу понять херня или нет:
Берем кейс редактирования с помощью формы. Редактирование не всей сущности. Из базы тянем только нужные данные, мапип на readmodel.
Страница редактирования: есть форма, чтобы ее заполнить, создаем ее на основе readmodel из базы
Экшен редактирования: для редактирования используется command который заполняется формой.
В итоге идентичные readmodel и command, плюс такие же поля в форме. В итоге при добавлении свойства в этот экшен придется менять практически 3 идентифичных файла. Особенно напрягает 1 в 1 readmodel и command. Что тут не так или это норм?
Берем кейс редактирования с помощью формы. Редактирование не всей сущности. Из базы тянем только нужные данные, мапип на readmodel.
Страница редактирования: есть форма, чтобы ее заполнить, создаем ее на основе readmodel из базы
Экшен редактирования: для редактирования используется command который заполняется формой.
В итоге идентичные readmodel и command, плюс такие же поля в форме. В итоге при добавлении свойства в этот экшен придется менять практически 3 идентифичных файла. Особенно напрягает 1 в 1 readmodel и command. Что тут не так или это норм?
Все норм
VS
Почему не важно
Иногда важно
Например в доктрине мы передаем название класса конекшена в итоге бы можем менять зависимость пусть эта зависимость и есть VO
Иногда важно
Например в доктрине мы передаем название класса конекшена в итоге бы можем менять зависимость пусть эта зависимость и есть VO
А что сервис для вас?
SB
Прерву:) Хэлпаните плиз, чет не могу понять херня или нет:
Берем кейс редактирования с помощью формы. Редактирование не всей сущности. Из базы тянем только нужные данные, мапип на readmodel.
Страница редактирования: есть форма, чтобы ее заполнить, создаем ее на основе readmodel из базы
Экшен редактирования: для редактирования используется command который заполняется формой.
В итоге идентичные readmodel и command, плюс такие же поля в форме. В итоге при добавлении свойства в этот экшен придется менять практически 3 идентифичных файла. Особенно напрягает 1 в 1 readmodel и command. Что тут не так или это норм?
Берем кейс редактирования с помощью формы. Редактирование не всей сущности. Из базы тянем только нужные данные, мапип на readmodel.
Страница редактирования: есть форма, чтобы ее заполнить, создаем ее на основе readmodel из базы
Экшен редактирования: для редактирования используется command который заполняется формой.
В итоге идентичные readmodel и command, плюс такие же поля в форме. В итоге при добавлении свойства в этот экшен придется менять практически 3 идентифичных файла. Особенно напрягает 1 в 1 readmodel и command. Что тут не так или это норм?
Я бы посоветовал команд бэйс интерфейс а не круд на команды накатывать
Такое себе
Такое себе
VK
У тебя запросто read model и команда могут отличаться
VK
В будущем
ПГ
У тебя запросто read model и команда могут отличаться
Ну это да, даже сейчас есть небольшое отличие в форматировании для формы. Просто выходит что 90% будет все равно одинаковое. Ок, спасибо.