Комментарии 26
После вступления — "Когда я высыпал на стол весь стек Windows-разработки, то понял, что ситуация — боль…" и КДПВ я ожидал какой-то жести. Вроде разработки солюшенов под Sharepoint (условие — на билд-севрере должны быть установлены Visual Studio и Sharepoint) или левых проприетарных тулчейнов (которые, конечно же, никто не додумался залить в NuGet).
А тут никакой жести, используются нормальные технологии на всех этапах...
Flyway идёт только в одну сторону, мы не можем откатиться назад — это существенный минус.
Но ведь это неправда.
Прежде всего команда разработки должна захотеть пересесть на .NET Core — после этого появляется и нормальный девопс процесс и релизы и это всё.
Интересная статья! Мы делаем несколько PWAs и у нас похожий стек, только вместо TFS используем TeamCity, ну и во frontend у нас Angular7 + Apache Cordova.
По поводу настройки редиректов в IdentityServer4. Эта проблема известная! Смотрите например тут — https://github.com/IdentityServer/IdentityServer4/issues/2598.
Для Flyway нам требовалась какая-то обертка, чтобы ребята не писали SQL-запросы. Им гораздо ближе оперировать в терминах ООП. Написали инструкции по работе с объектами БД, сформировался SQL-запрос и выполнился. Новая версия БД готова, прокаталась — всё хорошо, всё работает.
Странно почему ребята не посмотрели в сторону FluentMigrator. И туда и назад. Но в чистый назад я не верю. Лучше бакап перед миграцией. EF Core миграции еще тот минингит судя по фиксам и ломающим изменениям.
У Entity Framework Core есть минус — при больших нагрузках он строит не оптимальные SQL-запросы, и просадка по БД может быть существенной. Но так как у нас не высоконагруженный сервис, мы не исчисляем нагрузку сотнями RPS, мы приняли эти риски и делегировали проблему будущим нам.
У EF Core, большой минус, что он еще только родился. И если вы сидите на старых версиях — вы сами себе буратино, так как оптимизацией запросов они только начали заниматься. А там небольшой толк появляется только с .NET Core 3 — без малейшего понятия почему они так сделали, но что есть то есть.
И не при больших нагрузках, а в основном. Так складываются камешки в блоки потери производительности. Попросите ребят отключить предупреджение об client evaluation и превратить их в ошибки. Думаю 50% запросов у вас свалится. И это к лучшему, так как новая версия аннонсирует отключение client evaluation по умолчанию. Видать только так они могли сие стартануть в сроки (я их понимаю, это очень даже не просто).
- Серверной части WCF
- IKVM.NET (впрочем, её можно попробовать заменить на микросервис)
- LinqToSql (говорят, можно заменить на более современные Dapper или LinqToDB — но у них нет аналога SqlMetal, придется самим писать)
- EntityFramework 6 (кажется, EF Core до сих пор не умеет всего что умела прошлая версия)
- Файла web.config, в котором можно было не меняя кода настроить много интересных вещей
Linq2Sql разве жив? Простите, но чем вам EF не угодил? (сами мигрировали с первого на второе лет эдак пять назад).
Серверной части WCF в осязаемых планах у MSFT нет. Смотрите в сторону WebApi или gRPC (зависит от умения готовить и окружения).
WebApi и gRPC — это, конечно, хорошо — но спецификации Web Services они не поддерживают.
Linq2Sql разве жив? Простите, но чем вам EF не угодил?
Linq2Sql — это очень простой (и быстрый!) способ подключиться к существующей базе. EF тупо медленнее стартует, к тому же для него тоже нет аналогов SqlMetal
Серверной части WCF
WCF уже потихоньку уходит в прошлое, во многих проектах его уже давно и успешно заменил REST API.
LinqToSql (говорят, можно заменить на более современные Dapper или LinqToDB — но у них нет аналога SqlMetal, придется самим писать)
LinqToSql устарел во времена .NET 3.5 если не ошибаюсь, а любые генераторы кода — это в принципе зло и их необходимость, это признак того, что в проекте что-то не так с архитектурой.
EntityFramework 6 (кажется, EF Core до сих пор не умеет всего что умела прошлая версия)
Чего именно вам не хватает в EF Core?
Файла web.config, в котором можно было не меняя кода настроить много интересных вещей
appsettings.json также позволяет конфигурировать все то, что вы считаете необходимым сделать конфигурируемым. К тому же он значительно проще и в нем нету ада c bindingRedirect
WCF уже потихоньку уходит в прошлое, во многих проектах его уже давно и успешно заменил REST API.
Иногда REST просто не подходит, нужен RPC. А в этой области только веб-сервисы дают возможность сформировать машиночитаемую спецификацию (wsdl) и сгенерировать по ней клиент автоматически.
любые генераторы кода — это в принципе зло и их необходимость, это признак того, что в проекте что-то не так с архитектурой
Предложите альтернативу.
А в этой области только веб-сервисы дают возможность сформировать машиночитаемую спецификацию (wsdl) и сгенерировать по ней клиент автоматически.
gRPC также может генерировать «машиночитаемую спецификацию» через reflection для генерации клиента. Правда это не будет wsdl, но суть та же. Вообще, это не прерогатива одних только вёб-сервисов. И при желании можно экспозить gRCP как REST через автоматическую проксю.
любые генераторы кода — это в принципе зло и их необходимость, это признак того, что в проекте что-то не так с архитектурой
Кхм, можете развернуть сию мысль? Пока говорилось что генерится модель из базы, что я считаю единственно правильным способом работать с ней посредством LINQ.
EF Core + CodeFirst — опять же сами себе буратино. Надизайнят класов, намапят на базу, база как-то себе построится. Именно как-то, а не как надо. Потом через годик, когда данных в таблицы накидают, поймете где просчет и бегом это рефакторить.
Ужас берет от мысли какие после этого будут миграции и дай бог данные не потеряются.
Я видимо не совсем понял, что именно делает SqlMetal. Но если это просто инструмент для генерации простых моделей для ORM, то тогда мне в принципе не понятно, в чем проблема — EF Core это умеет.
В своем комментарии я больше говорил про подход, когда для решения каких-то задач используются инструменты для автоматического генерирования кода. Причем не моделей, а кусков логики. Встречал такие проекты. И это всегда было одним из серьезных симптомов того, что что-то явно не так в проекте.
- Да WCF нету, да я как-то и не плачу, вот только старые системы без него не перевести под .NET Core. Есть голосовалка, что бы вы хотели от порта
- LinqToDB не надо SqlMetal, у него есть T4 шаблоны которые генерят модель.
- EntityFramework 6 — есть порт. Но думаю уже EF Core на 90% совместим
- Файла web.config — как то мимо кассы
.NET Core на Linux, DevOps на коне