Комментарии 12
Странно, что это не было сделано при переходе с монолита на микросервисы.
Если у вас фреймворк настолько жёсткий, что надо было подключать бд даже если она не нужна, тут проблема скорее в тех, кто его написал ))
фреймворк работал на .NET 4.8. В 2021 году это уже стало жутким легаси
Я напомню, что .NET 4.8 вышел в апреле 2018 года. А в 2021 году работающий на нем фреймворк уже стал "жутким легаси"? Какие-то однодневные фреймворки в этом вашем IT...
Я напомню, что .NET 4.8 вышел в апреле 2018 года
Какие-то однодневные фреймворки в этом вашем IT
4.8 легаси уже был фактически на момент выхода, потому что то что тогда называли .NET Core уже активно параллельно развивался и всем было понятно что будущее за ним
.NET 4.* - это legacy в принципе:
принципиальное отсутствие поддержки .NET Standard 2.1;
принципиальная несовместимость с некоторыми свежими фичами языка C#;
устаревшая система сборки в комплекте;
ужасные конфигурационные файлы, в которых смешиваются настройки платформы и настройки приложения;
устаревшая архитектура системных классов (особенно в System.Web).
Многие вещи ощущались как неизбежное зло в 2016м году, но начиная с выхода .NET Core 2.0 вся старая ветка .NET перешла в категорию "всё ещё приходится использовать, но уже хочется свалить". А это и есть legacy.
Соответственно, все версии 4.7.1, 4.7.2, 4.8 и 4.8.1 были legacy ещё в момент релиза.
Если известное решение было неудобно, делали адаптер, к примеру MindboxValidation на базе FluentValidation — под капотом была технология, с которой все на рынке умели работать, а снаружи — привычный API.
Интересно было-бы пример посмотреть. Особенно - что было "неудобным" и как выглядит "привычный API".
я успел уволиться и поработать в другой компании
и в 2021 году вернулся
Как? Или просто в компании так и не смогли найти нового разработчика?
Легаси 14-летней выдержки: как мы отказались от фреймворка, пронизывающего всю разработку, — и выжили