.Net Middle Backend Developer
Скорее дело не в этом
По моему такое себе решение.
Если делать модельный монолит, то внутри какого то общего домена, например b2b web site:
Авторизация
Профиль юзера
Каталог товаров
Расценка
Корзина и заказ
История заказов
Если же сервисы между собой никак не связаны, то это такое себе.
Так же желательно сделать кажому сервису свою базу данных для возможности масштабирования.
Доступ к чужой бд, только через предоставляемый этим модулем shared интерфейс.
Сравнивал java и c# на уровне экосистемы и IDE. У Java убогая IDE.
На данный момент библиотеки otel для dotnet кривые.
EF Core Instrumentation вообще в бете и недавно втихаря подняли с dotnet 8 на 9 без изменения версии, изза чего у меня dotnet 8 сервис поломался.
Соглашусь. Но есть дополнительные методы расширения которые реализуют аналог While + можно использовать контекст через замыкание
Лучше сделать как в C# единый интерфейс IEnumerble для всех коллекций и методы расширения.
Linq лучше и удобнее чем tailreq
Было бы не плохо если бы вы делали еще статьи по написанию кода на Scala.
Например как написать микросервис на Scala:
Маршрутизация Rest API
Входные модели и валидация
Слой бизнес логики
Слой доступа к данным
Выходные модели и маппинг
Как построить структуру проекта, какая архитектура используется.
Как создать воркер-консюмер раббита или кафки.
Пора бы уже Scala 4.
Почему на Java Based языках все реализации ORM такие убогие
После EF Core выглядит довольно убого
Статья на уровне HelloWorld/
Чтобы это статья была действительно полезной нужно описать как создавать:
контроллеры
эндпоинты (GET\POST хотя бы)
как биндить параметры(примитивы и модели) из Route, Params, Body, Form.
Описать как производится валидация полей.
Следующей статьёй можно было бы описать фреймворк для работы с бд:
Создание доменных моделей
Создание конфигов моделей(Настройка полей, типов, PK, индексов, внешних ключей, отношений)
Чтение из бд включая с динамическими запросами с Where \ GroupBy\ OrderBy.
Как производится включение в запрос связанных сущностей
Создание \ Обновление \ Удаление
Когда понадобятся сложные динамические запросы будет боль и печаль
Проект не особо соответствует чистой архитектуре. Интрефейсы не выделены, сервисы и код связанный с БД в одном проекте.
От чистой архитектуры только пара названий.
Для логов, метрик и готовых аналитических витрин идеально подходит.
Мне нравится для логов - LSM-Tree + TLL + PARTITION BY toYYYYMM(DATE).
YDB под Windows Server?
Я про Scala => Java => Oracle
А библиотек - контейнеров DI нет?
На данный момент 5 вакансий по всей России
Потому что Microsoft это фуфуфу, а Oracle православный
Scala - сложнее.
Сложный код на Scala 1.5-2 раза больше.
Scala расходует больше памяти изза Immutable Scala Way.
Коллекции в Scala имеют более высокую алгоритмическую сложность изза иммутабельности.
Scala - легаси, большинство проектов так и остались на Scala 2.
Scala - убогая экосистема и зоопарк библиотек на коленке.
Скорее дело не в этом
По моему такое себе решение.
Если делать модельный монолит, то внутри какого то общего домена, например b2b web site:
Авторизация
Профиль юзера
Каталог товаров
Расценка
Корзина и заказ
История заказов
Если же сервисы между собой никак не связаны, то это такое себе.
Так же желательно сделать кажому сервису свою базу данных для возможности масштабирования.
Доступ к чужой бд, только через предоставляемый этим модулем shared интерфейс.
Сравнивал java и c# на уровне экосистемы и IDE. У Java убогая IDE.
На данный момент библиотеки otel для dotnet кривые.
EF Core Instrumentation вообще в бете и недавно втихаря подняли с dotnet 8 на 9 без изменения версии, изза чего у меня dotnet 8 сервис поломался.Соглашусь. Но есть дополнительные методы расширения которые реализуют аналог While + можно использовать контекст через замыкание
Лучше сделать как в C# единый интерфейс IEnumerble для всех коллекций и методы расширения.
Linq лучше и удобнее чем tailreq
Было бы не плохо если бы вы делали еще статьи по написанию кода на Scala.
Например как написать микросервис на Scala:
Маршрутизация Rest API
Входные модели и валидация
Слой бизнес логики
Слой доступа к данным
Выходные модели и маппинг
Как построить структуру проекта, какая архитектура используется.
Как создать воркер-консюмер раббита или кафки.
Пора бы уже Scala 4.
Почему на Java Based языках все реализации ORM такие убогие
После EF Core выглядит довольно убого
Статья на уровне HelloWorld/
Чтобы это статья была действительно полезной нужно описать как создавать:
контроллеры
эндпоинты (GET\POST хотя бы)
как биндить параметры(примитивы и модели) из Route, Params, Body, Form.
Описать как производится валидация полей.
Следующей статьёй можно было бы описать фреймворк для работы с бд:
Создание доменных моделей
Создание конфигов моделей(Настройка полей, типов, PK, индексов, внешних ключей, отношений)
Чтение из бд включая с динамическими запросами с Where \ GroupBy\ OrderBy.
Как производится включение в запрос связанных сущностей
Создание \ Обновление \ Удаление
Когда понадобятся сложные динамические запросы будет боль и печаль
Проект не особо соответствует чистой архитектуре. Интрефейсы не выделены, сервисы и код связанный с БД в одном проекте.
От чистой архитектуры только пара названий.
Для логов, метрик и готовых аналитических витрин идеально подходит.
Мне нравится для логов - LSM-Tree + TLL + PARTITION BY toYYYYMM(DATE).
YDB под Windows Server?
Я про Scala => Java => Oracle
А библиотек - контейнеров DI нет?
На данный момент 5 вакансий по всей России
Потому что Microsoft это фуфуфу, а Oracle православный
Scala - сложнее.
Сложный код на Scala 1.5-2 раза больше.
Scala расходует больше памяти изза Immutable Scala Way.
Коллекции в Scala имеют более высокую алгоритмическую сложность изза иммутабельности.
Scala - легаси, большинство проектов так и остались на Scala 2.
Scala - убогая экосистема и зоопарк библиотек на коленке.