Тут в принцыпе "пример ради примера" и не стал расписывать компенсирующие действия потому что стала бы сага тогда совсем огромной. Можно повесить Таймаут на сагу и если через 30 минут например не удалось провести операцию то начать пытаться до посинения откатить изменения в системе. Вернуть денги и предметы обрабтно или только деньги. Таймауты тоже настраиваются как перзистентные и тоже настраиваются с ретраями
И в MassTransit и в NServiceBus в реализации Saga есть перзистентность и возможность повторов выполнения т.е. они умеют после падения востанавливаться и продолжать свою работу там где они остановились.
Она упадет, потом сделает ретрай. Там пока в БД не будет записано что обработчик выполнился и выполнено действие оно будет повторяться. Либо до достижения лимита ретраев.
Тут надо в ней поля добавить для количества предметов и суммы денег что она себе забрала.
Дальше записываем данные в эти поля и потом уже делаем запрос на возвращение денег и предметов обратно. Да, консистентность со временем.
Для важных процессов ретраев делается много и с большим нарастающим промежутком между ними. Кроме того, в логи пишется если все ретраи выполнены и процесс не удалось завершить (Fault) и уже такие случаи можно индивидуально рассмотреть. Вообще через Jaeger это все трейситься обычно.
Тут для простоты фронт ждет ответа. Обычно записывают в БД Id таска при постановке задачи и дальше при событии оповещающем о том что сага завершила свою работу выставляют данные этом Таске в БД и еще в SignalR пушим что таск завершился. Фронт может и сам тоже проверить сделав запрос завершился ли Таск и какой у него результат.
public class DelayedTask
{
public Guid Id { get; set; }
public bool IsCompleted { get; set; }
public string ResultJson { get; set; }
}
Оу, спасибо! Отличная статься. Сам давно использую умные кострукторы в том числе и в C# только там бросаю эксепшены в контсрукторе или в методе set свойства.
Первым делом убрать всякие магические константы. Сделать вывод буквы более универсальным. Кривые Безье и так в типографии используются — вполне вероятно что можно найти готовую библиотеку с данными для них для любой буквы на любом языке и через эту библиотеку опорные координаты сделать чтобы можно было любой текст выводить. Сейчас не до того. На работе делаю важную вещь + по вечерам делаю сложный пет проект. Имена переменных поменял бы еще. Да там даже на первый глаз много что можно сделать лучше. Например я сейчас уже не понимаю зачем я через делегаты сделал вызов логики. Это можно убрать и сделать прямой вызов.
Хватит уже с ветрянными мельницами воевать. При старте приложения тот же SimpleInjector проверяет валидны ли все зависимости. Как и AutoMapper можно при старте прогнать на валидность все маппингов. Просто научись в уже в стартапе это прописывать и все. Реальная проблема может возникнуть только с либами что подключаются когда уже приложение запушено. Плагины всякие. С таким мне приходилось работать только когда сервер для игры писал. Обысно в Тырпрайсном приложении никто никаких либ не загружает в рантайме.
Хай, родной — оцени уровень ненависти к себе — у сбера есть школа 21 и там есть люди что учатся. Тобишь они идут дофига времени учится у сбера чтобы потом работать на сбер. Фаталити! :) Если серьезно — зря ты так банки ненавидишь.
Я мокаю X чтобы протестировать Y. Надо свой код протестировать на то как он себя ведет с различными входными данными. Если ты не умеешь писать чистый код и у тебя Ввод Вывод ака IO перемешан с твоей логикой то ты ССЗБ.
Все фигня кроме ёжиков потому что ёжики не фигня. Ты Балдурс Гейт 3 видел? Я смотрел стримы и по моему годнота. Хочу поиграть ток ранний доступ и забагованно все к чертям. Да и только первый акт открыть. Я теперь жи буду это — в нетерпении ждать пока не выйдет полная версия. В принцыпе пока что можно в Дивинити 2 поиграть. БД 3 таки очень на Дивинити похожей вышла. Один фиг, растравили мне душу теперь руки чешутся по скорее поигать.
Вообще с тестами это на практике приходит. Я лично вижу и как сделать чтобы покрыть тестами и какие граничные варианты. Начиная писать код с желанием максимально покрыть его тестами и сделать поведение предсказуемым я потихоньку научился код писать тестируемым и расширяемым. Тесты они меняют твой стиль кода и начинаешь в принцыпе писать код так чтобы он был тестируемым и с маленькими понятными Юнит Тестами.
Вообще фишка маленьких чистых методов и функций (вроде того же метода на сравнение по From и To) что для них можно такие же маленькие и Проперти базед тесты писать.
Почему нельзя код что тут на скриншоте вынести в функцию и покрыть ее проперти тестами? Почему нельзя замокать веб сокет и прочую петрушку? На самом деле надо завязывать — один фиг без глубокого погружения и не видя всего кода со всей задачей мне сложно тебе рассказать как тут правильно сделать.
Это как раз пример «логов вместо отладки» который я говорил. Когда хочется в логах видеть, как идет флоу и в какой момент он пошел не так, как должен был. Юнит тесты тут вообще не при чем, эта функциональность на регрессе проверяется.
Так тестами можно было этот флоу описать. Что если вот так то должно делаться вот так. Если есть входные и выходные данные из логов то можно было реально с ними продебажить в специально созданном тесте — просто в моки и стабы данные нужные выставить и дебажить. Ну как тест — это уже просто экспериментальный запуск. Хотя там такое, я всего кода не вижу. Может там дофига внешнего взаимодействия и написать моки/стабы был бы дикий гемморой.
Ты чего такой токсичный? Если там этот кусок кода для тебя был как родной и тебя эта моя фигня сильно задела то прости. Забей вообще на мой комментарий. Люблю тебя.
Тут в принцыпе "пример ради примера" и не стал расписывать компенсирующие действия потому что стала бы сага тогда совсем огромной. Можно повесить Таймаут на сагу и если через 30 минут например не удалось провести операцию то начать пытаться до посинения откатить изменения в системе. Вернуть денги и предметы обрабтно или только деньги. Таймауты тоже настраиваются как перзистентные и тоже настраиваются с ретраями
И в MassTransit и в NServiceBus в реализации Saga есть перзистентность и возможность повторов выполнения т.е. они умеют после падения востанавливаться и продолжать свою работу там где они остановились.
Она упадет, потом сделает ретрай. Там пока в БД не будет записано что обработчик выполнился и выполнено действие оно будет повторяться. Либо до достижения лимита ретраев.
Тут надо в ней поля добавить для количества предметов и суммы денег что она себе забрала.
Дальше записываем данные в эти поля и потом уже делаем запрос на возвращение денег и предметов обратно. Да, консистентность со временем.
Для важных процессов ретраев делается много и с большим нарастающим промежутком между ними. Кроме того, в логи пишется если все ретраи выполнены и процесс не удалось завершить (Fault) и уже такие случаи можно индивидуально рассмотреть. Вообще через Jaeger это все трейситься обычно.
Тут для простоты фронт ждет ответа. Обычно записывают в БД Id таска при постановке задачи и дальше при событии оповещающем о том что сага завершила свою работу выставляют данные этом Таске в БД и еще в SignalR пушим что таск завершился. Фронт может и сам тоже проверить сделав запрос завершился ли Таск и какой у него результат.
Оу, спасибо! Отличная статься. Сам давно использую умные кострукторы в том числе и в C# только там бросаю эксепшены в контсрукторе или в методе set свойства.
Так тестами можно было этот флоу описать. Что если вот так то должно делаться вот так. Если есть входные и выходные данные из логов то можно было реально с ними продебажить в специально созданном тесте — просто в моки и стабы данные нужные выставить и дебажить. Ну как тест — это уже просто экспериментальный запуск. Хотя там такое, я всего кода не вижу. Может там дофига внешнего взаимодействия и написать моки/стабы был бы дикий гемморой.