АВ
ну или через lazy можно было бы наверное, вместо чтоб жабу 1:1 портировать
member this.GetValue = getValue() получишь пропертю с геттером и окSize: a a a
2020 June 09
VS
Андрей Вилинский
а если так?
можно, но там лучше именно фукнцию) чтобы юзер понимал что это не просто геттер поля, а там что-то происходит
VS
Андрей Вилинский
да, похоже тебе надо combineLatest или хз как там оно точно называется
и да энумератор это структура, получаешь разные на каждый вызов
и да энумератор это структура, получаешь разные на каждый вызов
комбайн тупл создает ( мне нужно чтобы остался асинксек того же типа после мержа
АВ
Андрей Вилинский
да, похоже тебе надо combineLatest или хз как там оно точно называется
и да энумератор это структура, получаешь разные на каждый вызов
и да энумератор это структура, получаешь разные на каждый вызов
да, уже посмотрел https://rxmarbles.com/#merge
PD
Добрый день всем!
Хотел бы спросить вопрос, связанный с архитектурой. Попытался я накалякать репозиторий, разделить по слоям, и в итоге получилась следующая картина:
Хотел бы спросить вопрос, связанный с архитектурой. Попытался я накалякать репозиторий, разделить по слоям, и в итоге получилась следующая картина:
PD
Переслано от Prunkles Dreemurr
Я таки поделил репозиторий на 2 слоя: низкие и высокие функции. Будем рассматривать на примере получения юзера
1. Принимает сырой тип гуид, возвращает асинхронного ридера, у которого окружением является DbContext, а результатом исполнения является DAO модель. Короче действительно низкоуровенщина
2. Теперь окутаем функцию из [1] пункта в домен. А именно, отныне аргумент — не сырой гуид, а доменная модель UserId , а возвращаемое значение тоже теперь не UserDao , а доменная модель User. Очевидно, что при парсинге UserDao в User могут возникнуть ошибки — их тоже возвращаем в качестве неуспешного результата. Окружением всё также является только DbContext
3. (Только что написал) Функция уже практически самого высокого слоя — принимает доменный айди юзера, а возвращает опшн юзера (есть/нет), и если нет, то залогировать это дело. Тут уже окружением является "общим", которое содержим как контекст, так и логгер. Однако находится на слое application layer, что немного выходит из стандартной модели
1. Принимает сырой тип гуид, возвращает асинхронного ридера, у которого окружением является DbContext, а результатом исполнения является DAO модель. Короче действительно низкоуровенщина
2. Теперь окутаем функцию из [1] пункта в домен. А именно, отныне аргумент — не сырой гуид, а доменная модель UserId , а возвращаемое значение тоже теперь не UserDao , а доменная модель User. Очевидно, что при парсинге UserDao в User могут возникнуть ошибки — их тоже возвращаем в качестве неуспешного результата. Окружением всё также является только DbContext
3. (Только что написал) Функция уже практически самого высокого слоя — принимает доменный айди юзера, а возвращает опшн юзера (есть/нет), и если нет, то залогировать это дело. Тут уже окружением является "общим", которое содержим как контекст, так и логгер. Однако находится на слое application layer, что немного выходит из стандартной модели
PD
PD
PD
Хотелось бы оценку
PD
P.S. Логгирование специально не стал делать врайтер монадой, ибо это неоправдано усложняет испольвание. Но имхо использование ридеров я нашёл очень удобным
VS
В общем с асинксеком вопрос почему возник - у меня такая задача, есть родительский консьюмер, который собирает консьюмы дочерних консьюмеров в один асинксек и делает MoveNext() на каждом свое ресиве. И все было хорошо, но мне нужно поддерживать динамическое добавление консьюмеров, я думал сделать просто merge к существующему стриму, но что-то это не работает нормально похоже из-за того что нужно заново энумератор пересоздавать ( Мб есть идеи как решить проблему?
Вот, сделал другое репро проблемы - первый асинк вызывается после мержа, хотя я его не просил) непонятно как это обойти
https://pastebin.com/JHh2qSHN
https://pastebin.com/JHh2qSHN
PD
Переслано от Prunkles Dreemurr
Я таки поделил репозиторий на 2 слоя: низкие и высокие функции. Будем рассматривать на примере получения юзера
1. Принимает сырой тип гуид, возвращает асинхронного ридера, у которого окружением является DbContext, а результатом исполнения является DAO модель. Короче действительно низкоуровенщина
2. Теперь окутаем функцию из [1] пункта в домен. А именно, отныне аргумент — не сырой гуид, а доменная модель UserId , а возвращаемое значение тоже теперь не UserDao , а доменная модель User. Очевидно, что при парсинге UserDao в User могут возникнуть ошибки — их тоже возвращаем в качестве неуспешного результата. Окружением всё также является только DbContext
3. (Только что написал) Функция уже практически самого высокого слоя — принимает доменный айди юзера, а возвращает опшн юзера (есть/нет), и если нет, то залогировать это дело. Тут уже окружением является "общим", которое содержим как контекст, так и логгер. Однако находится на слое application layer, что немного выходит из стандартной модели
1. Принимает сырой тип гуид, возвращает асинхронного ридера, у которого окружением является DbContext, а результатом исполнения является DAO модель. Короче действительно низкоуровенщина
2. Теперь окутаем функцию из [1] пункта в домен. А именно, отныне аргумент — не сырой гуид, а доменная модель UserId , а возвращаемое значение тоже теперь не UserDao , а доменная модель User. Очевидно, что при парсинге UserDao в User могут возникнуть ошибки — их тоже возвращаем в качестве неуспешного результата. Окружением всё также является только DbContext
3. (Только что написал) Функция уже практически самого высокого слоя — принимает доменный айди юзера, а возвращает опшн юзера (есть/нет), и если нет, то залогировать это дело. Тут уже окружением является "общим", которое содержим как контекст, так и логгер. Однако находится на слое application layer, что немного выходит из стандартной модели
Ну или вот такой вариант "всё в одном". Бесспорно, выглядит проще, но делать мелкими функциями кажется более правильным
SN
Хотелось бы оценку
"это пинцет"
SN
в нормальных языках репозиторий - это один компонент, а у тебя три слоя, две монады и одна плашка на 5\16
SN
" Очевидно, что при парсинге UserDao в User могут возникнуть ошибки" - это вообще ни грамма не очевидно
PD
" Очевидно, что при парсинге UserDao в User могут возникнуть ошибки" - это вообще ни грамма не очевидно
Ну как же? А кто же говорил, что доверять бд нельзя?
SN
Ну как же? А кто же говорил, что доверять бд нельзя?
откуда я знаю, кто это говорил? в нормальных проектах БД доверять вполне можно.
SN
ты можешь не прочитать вообще ничего из бд (сеть, сама бд и т.п), но если ты прочитал - то там должно быть только то, что ты туда сам записал.
SN
вы там шарите БД что ли?
YN
что такое пинцет. плашка на 5/16, жаргон какой-то, сложна