company_banner

.NET Community Meetup 29/10

    Были рады встретиться онлайн на .NET Community meetup 29 октября. Общались на тему дизайна и использования асинхронного Success/Failure-пайплайна в микросервисах и погрузились в историю языков программирования — что позаимствовали авторы C# у людей, про которых мы даже и не знаем?

    Пропустили митап? Делимся записью и презентациями спикеров :)

    О чем поговорили


    Асинхронный Result-флоу для .NET

    Андрей Сергеев, Райффайзенбанк

    Ответы на вопросы
    > Интересно, как такой подход влияет на дефекты :) Пилить в контроллерах всю бизнес логику и радоваться жизни — это жесть.
    Мы не пишем логику в контроллерах, для этого есть слой логики. На одном из будущих докладов расскажем о нашем подходе к разделению сервисов на слои. Мы не допускаем смешения обязанностей в слоях.

    > В таком коде надо 15 минут разбираться, чтобы отделить бойлерплейт код от логики.
    Особенность языка C# — статическая типизация. Иногда приходится писать бойлерплейт код, например, из-за перегрузки методов для Task и ValueTask (в нашем случае). В стандартной библиотеке .NET также много бойлерплейт кода, например, в том же LINQ. И ок, если бойлерплейт написан на библиотечном уровне и отлажен. В результате чего бойлерплейт минимизируется в клиентском коде.

    > Можно ли создать конвейер Result с ветвлениями и циклами? LINQ не пробовали привязать?
    Если речь о том, чтобы в конвейере возвращаться на N шагов назад, то нет. Или это будет уже не конвейер, к тому же это будет уже нечто stateful. Однако можно создать модель с циклами/ветвлениями и даже конечный автомат, которые внутри будут пользоваться конвейером. А модель более верхнего уровня будет пользоваться этой моделью тоже в конвейер-стиле. Другими словами, мы можем написать набор функций на базе конвейера, а пользоваться этими функциями может и stateful-модель.

    > Что будет, если функция, вызываемая в конвейере, бросит Exception?
    Теоретически в Result-подходе исключение должно быть фатальным. Однако для обработки таких случаев для движения по конвейеру без падения есть методы PipeCatching, RecoverCatching.

    > То есть нужные данные придётся тащить через весь конвейер?
    Идея конвейера в том, что на каждом шаге конвейера данные преобразуются в соответствии с уровнем абстракции каждого шага. Если какие-то данные проходят через N шагов без изменений, то либо так задумано, либо это неправильная проработка модели.

    > А можно показать код обработки ошибок типа неправильные креденшалсы, или ненайден ID-шник пользователя. Или, например, ответ от бд в таймауте?
    В первом приближении это уже было в докладе, где выполнялся Fold и преобразование ошибки в HTTP-код, там, где, как уже отметили в одном из вопросов, мы для наглядности в докладе вытащили всю модель в контроллер.

    Но вопрос понятен — на сессии вопросов и ответов договорились, что сделаем доклад с «живым», не синтетическим примеров (не раскрывая при этом бизнес-данных и тд).

    > Как будет реализовано ветвление if-then-else?
    Если ветвление небольшое, то это вполне можно сделать в стратегии, передаваемой в методы конвейера. Либо, если это принципиально и нужно отразить на уровне конвейера, то нужно воспользоваться тем, что у конвейера есть 3 группы методов непосредственно Pipe, плюс Recover и Filter.

    > Я правильно понял, что при таком подходе DI не применим? Так как весь pipeline представляет собой static классы.

    DI применим. Реальные реализации типов, участвующих в конвейере — не статические. Это sealed класс для AsyncResultPipeline и readonly-структуры для AsyncPipeline и Result. При этом модель конвейера — stateless, то есть там нет глобального состояния. Состояние есть чисто техническое — то, что, например, AsyncPipeline оборачивается в AsyncResultPipeline

    Другое дело, при чем здесь DI. Конвейер не предполагается прокидывать как зависимость.
    Сама идея конвейера — получили значение, пробежались по конвейеру, в конце выполнили Fold. Это ФП с stateless-подход. Другое дело, что приложение/сервис могут быть и stateful, но реализация методов в этом приложении может быть на базе конвейера.

    Так что DI и конвейер темы непересекающиеся. Однако на тему DI у нас будет доклад 19 ноября. Мы представим Dependency Pipeline как альтернативы Dependency Injection

    ПРЕЗЕНТАЦИЯ

    О спикере: Андрей — разработчик программного обеспечения. Занимается проектированием и разработкой back-end платформ и продуктов, фокусируясь на дизайне архитектурных слоев и связей между ними: от ядра, движка — технического фундамента, до уровней, реализующих в более высоких терминах предметные задачи, и далее до конечных точек (внешних контрактов). Использует актуальные .NET Core и C#, применяя в качестве основного функциональный подход — от использования языковых конструкций и принципа композиции до организации слоев в микросервисах и далее потоков между сервисами; при этом, обогащая подходы к разработке результатами анализа смежных и/или конкурирующих инструментов (F#, Java, Kotlin, Ruby и др.) и принципов (например, динамической типизации). При этом, ориентируясь на актуальные инструменты, исходит из первичности принципов, которые уже затем реализуются с помощью тех или иных средств.

    О докладе: дизайн и использование асинхронного Success/Failure-пайплайна в микросервисах с учетом особенностей реализации асинхронных вычислений в C# и .NET.


    История языков программирования для тех, кто пишет на C#

    Марк Шевченко

    ПРЕЗЕНТАЦИЯ

    О спикере: Программист и тимлид. В свободное от работы время организует встречи Московского клуба программистов.
    В рамках клубной работы помогает программистам делать интересные доклады и писать хорошие статьи. На основной работе руководит небольшим коллективом специалистов. Показывает, как писать простой код, покрывать его тестами, использовать паттерны проектирования и применять принципы SOLID. Понимает, что такое внедрение зависимостей и предметно-ориентированное проектирование. Делает доклады, пишет статьи, ведет курсы по программированию.

    О докладе: нам с вами очевидно, что C# — хороший язык программирования. Смотришь, как замечательно авторы его спроектировали, и сердце радуется! Правда, копнув глубже, понимаешь, что авторы позаимствовали некоторые идеи у людей, про которых мы даже и не знаем, и идеям этим десятки лет. Исследуем историю языков программирования. Посмотрим, что волновало программистов в прошлом, и как это повлияло на современный мир.
    Райффайзенбанк
    Развеиваем мифы об IT в банках

    Похожие публикации

    Комментарии 2

      0
      Выложите уже ссылку на код в git с хелперами для этого пайплайна. Необязательно дотачивать до совершенства, комьнити и доточит. Тем более вроде у вас всё уже полгода в продакшоне работает. Или по другим причинам код зажали?
        0
        Добрый день! Мы планируем выложить и поделиться. И, конечно, заинтересованы во влиянии на развитие .NET-сообщества в целом. К сожалению, на данный момент сроки уточняются по ряду причин. Вернемся в эту ветку, как будет информация :)

      Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

      Самое читаемое