Миграция проекта с ASP.NET Web Forms на Blazor
Нашёл такие ресурсы по миграции
Blazor for ASP.NET Web Forms Developers | Microsoft Docs
From Web Forms to Blazor - Introducing the Blazor Web Forms Components - YouTube
Что понял, что если на веб-формах было изначально написано модульно, то по сути надо только перенести UI-часть и немного обновить модули (возможно, там старые версии фреймворка и доступа к данным использовались), ну и добавить немного конфигураций для Blazor-проекта для подключения этих модулей. Как я понял, в Blazor всё делается через dependency injection, включая внедрение того же доступа к БД через модель БД, созданную, например, через Entity Framework.
UI-часть придётся переписывать страница за страницей вручную... Ну или есть разные типа конвертеры, но за ними всё перепроверять нужно. Особенно разные кастомные компоненты на веб-формах нужно будет в любом случае заново написать на Blazor. А ещё некоторые стандартные из веб-форм контролы не имеют прямых аналогов в HTML - тоже придётся делать замены. Т.е. это всё нужно в ручном режиме проработать.
Не существует каких-то автоматических конвертеров, добавлятелей Blazor UI для старых проектов на веб-формах через мастер-конфигуратор. В любом случае миграция будет представлять из себя новый проект, в котором будет полностью переписана UI-часть и, в лучшем случае, использованы слегка доработанные старые модули. В случае же, если старое веб-формы приложение было не разделено на модули или плохо разделено - всё было в code behind обработчиков событий написано, то придётся переписывать вообще всё приложение.
Итого миграция ASP.NET Web Forms to Blazor - это переписывание значительной части или всего приложения. Почти как новый проект по спецификации написать сразу на Blazor. Так?
Почти как новый проект по спецификации написать сразу на Blazor. Так?
Скорее всего так. Еще и + .Коре
Но получится гораздо проще и удобнее. Проблема только UI найти подходящую
Ну и где хостить тоже проблема.
Если есть еще логин и "по-старому", то ой
Я server-side предложу вариант, а не веб-ассембли на клиенте.
А что с логином? В веб формах какой-то замшелый вариант используется, который на Blazor не натягивается?
И почему Коре? Там же вовсю уже .NET 5 и 6 используются?
Я server-side предложу вариант, а не веб-ассембли на клиенте.
У каждого есть свои недостатки. У серверного только необходимость обновления signalR сессии. На "своем" сервере особых проблем не замечал.
А вот на Azure не всегда пересоединяется хорошо.
И почему Коре?
Пока не встречал блазора без него. Да и взаимодействие с JS без .NET 5 не очень приятно
А что с логином?
надо просто смотреть. "Из коробки" будет немного по другому.
Ещё, как я выяснил, проект, похоже, на старой версии фреймворка работает - вообще 2.0 или что-то такое (проект в 2002 года идёт, и неизвестно пока, до какой версии они всё обновляли). Т.е. даже если там модульно что-то написано, нужно будет весь код обновить до той версии, на которой новое приложение будешь писать... Или как-то можно заставить код .NET 2.0 заставить работать в среде 5.0 (без обмена всякими джейсонами и тому подобное "интероперабилити")?
Ну и если там база данных кундов, то придётся новую систему авторизации-аутентификации на базе этой БД делать?
PWA полностью standalone, или как-то общается с сервером? Если да, то общается независимо от сервисов на стороне сервера (через тот же REST, написаны на любом языке), или через так называемый Blazor Server?
Я понимаю. Я говорю про то, что у Blazor же есть серверная составляющая - была ли она у вас? Может, там при старте интенсивное общение с сервером было, потому и так долго стартовало?
Ангуляр не общается с сервером и потому стартует быстро?
Google Mail загружается 5-10 секунд, имхо вроде сделан на ангуляре, а сам обычный ангуляр имхо весит 4 мегабайт, а тот который для nodejs весит аж 34 мегабайт, там очень много всяких модулей.
Вы вроде занимались Блейзором? Клиентской версией с веб-ассембли, или с серверным рендерингом через SignalIR?
Вы переписали ваше приложение на Блейзор, протестировали и отказались, или только тестовый кусочек сделали?
Ойляяяя... Читаю описание, как в Blazor работает рендеринг составных шаблонов. Помню, ещё в в ASP.NET MVC оно было запутанным, а тут ещё немного запутали.
В WPF всё проще - вот модель, вот её шаблон представления. В Blazor надо прыгать по 3 файлам (особенно, если для компонента вместо кода и разметки вперемешку используется отдельный файл с кодом) в разном порядке и по нескольку раз, чтобы понять, что куда отрисовывается. Какого-то хрена в Blazor описание шаблона разделено на две части - для всего компонента и для отдельных свойств. При этом шаблоны для свойств должны быть тут же по месту использования компонента:
<Component TypeParam="" Property1="" Property2="">
<Property1> - это шаблон для свойства, а есть ещё шаблон для всего компонента - в другом файле
<разметка>
</Property1>
<Property2> - шаблон для другого свойства
<разметка>
</Property2>
</Component>А нельзя как в WPF - один дефолтный шаблон на тип и, если надо, template selector? А конкретное определение шаблона по месту сделать опциональным?
Или это можно сравнить с разными типами шаблонов в WPF. Тогда шаблон для всего компонента в Blazor это аналог шаблона представления в WPF, а шаблоны для свойств в Blazor - это аналог шаблона данных в WPF.
Вы переписали ваше приложение на Блейзор, протестировали и отказались
Готовое приложение на блазоре работает относительно нормально, особенно если не на Azure хостится.
А вот для PWA делали спец. тест Blazor vs Angular - просто небольшое приложение. Потом еще одно для CPU интенсивных задач.
Если нужно только исключительно веб использование с десктопа, без особых хотелок, то работает нормально. Делаем серверный пререндинг и приложение запускается и в первый раз быстро.
В Blazor надо прыгать по 3 файлам
А третий какой? Можно всё в одном сделать но мне так не нравится.
Что то проблему не могу понять
https://blazor-tutorial.net/component-parameters
Что называете шаблоном?
А третий какой?
Файл razor с разметкой компонента, файл razor.cs с шарповским кодом, файл, что я выше показал - место, где компонент непосредственно используется и где задаются шаблоны для его свойств. Ну и можно привести четвёртый файл - стили. Т.е. чтобы работать с Blazor нормально, нужно минимум четыре окна открытыми держать одновременно, иначе задолбаешься переключаться.
Что называете шаблоном?
Templated components
https://docs.microsoft.com/en-us/dotnet/architecture/blazo...
Без этих шаблонов ни нормального списка, ни нормального тривью, ни таблицы не сделать. Не руками же в форичах перебирать каждый узел структуры данных.
При этом заметьте, как запутана логика отрисовки - чтобы понять, что будет в итоге, чёрт ногу сломит метаться между файлами:
1) встречаем такую разметку, которая использует компонент
<ChildContentComponent>
<ChildContent>
<p>The time is @DateTime.Now</p>
</ChildContent>
</ChildContentComponent>2) идём в code-behind смотреть, что это за ChildContent
@code {
[Parameter]
public RenderFragment ChildContent { get; set; } }3) смотрим в разметке компонента, куда будет отрисован ChildContent
<h1>Component with child content</h1> <div>@ChildContent</div>
4) пытаемся собрать воедино всю эту бурду - вставляем в ChildContentComponent (пункт 1) разметку из компонента (пункт 2)
<ChildContentComponent>
<h1>Component with child content</h1>
<div>@ChildContent</div>
</ChildContentComponent>5) убираем лишнее обрамление (оно не отрисовывается в конечной HTML-разметке)
<h1>Component with child content</h1> <div>@ChildContent</div>
6) вставляем в свойство ChildContent его шаблон (снова возвращаемся за ним в пункт 1)
<h1>Component with child content</h1> <div><p>The time is @DateTime.Now</p></div>
Вот что будет отрисовано вместо изначальной разметки в пункте 1.
Офигеть как всё запутали! И это простой случай - без кучи параметров со своими шаблонами, без иерархических шаблонов, без привязок, без параметров типа и без рекурсивных отрисовок шаблонов (нужно для отрисовки древовидной структуры данных). Конечно, можно привыкнуть к любому дерьму, но почему, ска, обязательно через задницу всё?!
Ещё не забудьте такой долбанутый параметр как Context, про который в МСДН не объяснено толком, что это такое. В этой разметке
<SimpleListView Items="messages" TItem="string">
<Heading>
<h1>My list</h1>
</Heading>
<ItemTemplate Context="message">
<p>The message is: @message</p>
</ItemTemplate>
</SimpleListView>это, оказывается, экземпляр объекта типа, переданного в параметре TItem. Т.е. если у типа в TItem есть свойства, то их можно достать через @context.MyProperty, или переименовав параметр context в удобный, как показано выше, чтобы он назывался не context, а соответственно объекту. В примере это просто строка message, но можно обращаться к её свойствам, типа @message.Length.
Готовое приложение на блазоре работает относительно нормально, особенно если не на Azure хостится.
А вот для PWA делали спец. тест Blazor vs Angular - просто небольшое приложение. Потом еще одно для CPU интенсивных задач.
Я думал, вы в одиночку всё переписали.
Это где такое бесплатное с три вью?
А что гугла молчит как партизан на допросе? 
А это принципиальное решение, что в проекте Блейзор с подключенным EF Core нет шаблона в визуальном меню для генерации контекста БД (ADO.NET Data Model или что-то такое, как было раньше через меню Add - New Item), и всё надо делать через командную строку с кучей параметров? Ещё и две версии сделали, чтобы жизнь лёгкой не казалась
https://learn.microsoft.com/en-us/ef/core/cli/dotnet#dotne...
https://learn.microsoft.com/en-us/ef/core/cli/powershell?s...
Теперь вместо того, чтобы быстро через меню добавить что нужно, я должен изучать эту портянку с кучей параметров, городить длиннющую строку команды и куда-то в консоли её вводить?
Письма разносил
Да это я не вам лично, а вообще. Просто ваше сообщение последнее, а просто "ответить в тему, никому" тут нельзя. ))
нет шаблона в визуальном меню для генерации контекста БДА зачем? Они ориентированы на code first. DevArt отлично справляется с DB First.
Или Я что тот не понимаю?
Раньше был так называемый мастер (серия форм с настройками) для создания контекста БД по существующей БД. А теперь надо команду какую-то формировать, путаясь в её синтаксисе. А если надо много опций, выбор конкретных таблиц, то команда может на несколько строк растянуться. Дебильный подход для любителей командной строки. Вместо того, чтобы в нескольких окнах мастера потыкать опты и выбрать нужные таблы.
для создания контекста БД по существующей БД
Ну так это и есть DB First. Ms считает что оно не сильно так и нужно.
Что в принципе и правильно эту фигню от мелкософта никак не хочется использовать. Достаточно попробовать Entity Developer
А зачем какая-то тулза, тем более ещё и безапелляционно платная, если стандартный бесплатный мастер делал всё нужное, просто протыкав несколько опций? Ну мне не нужны лишние изъёпства, пусть даже этот Entity Developer супер-пупер - просто нужно простой ORM-контекст накидать, чтобы руками не возиться.
А давайте все мастера и тулзы в Студии заменим пачкой команд с портянкой параметров? Круто же будет? И вообще, выкинем эту сраную Студию, а будем всё компилить из командной строки, как тут в примерах. Сравните переключатели для одного и того же шага в Винде, Линухе и Макоси. В Винде - нормальные визарды с менюшками. Для мамкиных красноглазиков - портянки в командной строке с пачками параметров. Сразу виден подход нормальных людей и сумасшедших, затрявших в семидесятых годах прошлого века.
Сто лет назад, когда программ на компе было по пальцам одной руки, и параметров у них было тоже не больше, можно было всё запомнить и вводить эти команды. А теперь, когда прог и тулзов сотни и тысячи, и у каждой море параметров, то запоминать (или высматривать в справочниках) и вводить эти портянки - проще клаву об голову придумавшего это разбить. ))
Мс делает то, что удобно им. Раз им не нужно то и остальным также. Обсуждать тут вроде нечего, разве что как более удобно это обойти.
Лично у меня не возникало желания с ЕФ начинать с БД. Один раз было интересно пробовать, но заломало во всём разбираться, да и без редактора БД неудобно.
А так редактор есть, нажал сгенерить и всё готово, причем можно настроить чтобы генерились только определённые таблицы.
Так и у меня уже готовая БД. И прежняя бесплатная тулза в комплекте со Студией тоже умела и выбранные таблицы генерить, и имена им плюрализовать-сингуляризовать. Тока теперь вы за это бабки платите. И не просто, а две-три сотни самый минимум. Хренасе - на Юнити 3Д за две-три сотни такой набор покупается, что игра делается просто натыкиванием готовых ассетов по автосгенеренной карте. Затем добавляешь лутбоксы, покупаешь рекламу и вуаля - ты миллионер (через пару лет, если повезёт). А тут за сраный маппинг столько по минимому отдать. ))
и выбранные таблицы генерить
И всё остальное? Дома мне хватает и за 120
https://www.devart.com/entitydeveloper/features.html
За бесплатно пользуйтесь командной строкой ну или петицию в спортлото что мс гады убрали клёвую тулзу.
Я не раз наблюдал, как сами разработчики из МСа по-бырому добавляли разные тулзы и фреймворкочки к недавно вышедшим дефолтным тулзам и фреймворкам МСа. Зачастую - добавляли платно. Т.е. этакий изъян, как-будто сделанный при разработке специально, чтобы было "room for improvement making the money". Потому, конечно, спустя два-три релиза функционал дефолтных бесплатных тулзов допиливают, так что платные уже можно оставить. Но несколько лет за платные ты всё равно заплатишь. И сказать, что они не успевали добавить платный функционал в бесплатный, нельзя. Т.е. они на работе не успевали, а потом после работы резко успели (только за доп. деньги). Причём так успели, что после работы, по вечерам, за несколько месяцев напилили функционала, который потом в бесплатный вариант будут годами добавлять (копипастом, я так
понимаю).
Хитровы...е, короче. ))) Интересно, им так дают подзаработать? Т.к. бабки идут не в кассу МС, а команде МС лично, как я понимаю. Оно им и сподручней, конечно - они же сами это разрабатывали и знают, как там всё работает.