Před pár dny jsem natočil video o tom, jak vzít starou ASP.NET Web Forms aplikaci a postupným procesem ji zmigrovat na .NET Core. Během pár dní video získalo několik stovek shlédnutí, což mě docela příjemně překvapilo.
Přepsat nebo udržovat a modernizovat?
Všechny aplikace časem zastarávají. U těch webových je největší problém s frontendovou částí, protože tam se technologie a postupy střídají velmi často. Jen za posledních 15 let jsem zažil asi pět různých přístupů k tvorbě webového UI – od čistého HTML a velmi opatrného používání jednořádkových skriptů důsledně doplňovaných elementem noscript, přes počátky AJAXu následované obrovským rozmachem jQuery, až po nástup velkých frameworků jako Knockout, Angular, React a Vue. Dnes možná začíná další etapa s názvem Web Assembly.
Backend je o dost konzervativnější, i dnes většina aplikací používá relační databázi a ve světě .NETu dominuje Entity Framework, který je s námi více než 10 let. I zde se ale hodně změnilo a .NET Core přinesl mnoho vylepšení, zejména v oblasti infrastruktury pro dependency injection, logování, konfiguraci a další.
Letos na Buildu Microsoft oznámil, že po .NET Core 3.0 bude následovat .NET 5 (nástupce .NET Core), a zároveň že technologie, které na .NET Core nebyly zatím portovány, už na něj portovány nebudou.
Pokud jste tedy používali Windows Communication Foundation, můžete se zkusit zapojit do vývoje Core WCF, které bylo nedávno přijato do .NET Foundation. Pokud potřebujete Workflow Foundation, existuje též její open source varianta. Portování nebude jednoduché, protože .NET Core má mnoho věcí jinak, ale pokud používáte jen základní funkce, možná to nebude tak hrozné – aplikaci jen bude chtít komplexně otestovat, protože tam mohou být různé breaking changes.
Nejsložitější situace je u ASP.NET Web Forms. Port Web Forms na .NET Core neexistuje, ani ne tak kvůli markupu, ale zejména kvůli starému API ze System.Web, které je úzce svázáno s IIS a na .NET Core v podstatě nejde přeportovat. I kdyby někdo přepsal Web Forms view engine, aplikace by pravděpodobně přestaly fungovat ve chvíli, kdy by se pokusily sáhnout na cokoliv ze třídy HttpContext – ta by se musela nějak provázat s HttpContextem na .NET Core, ale vzhledem k tomu, že většina věcí tam funguje dost jinak, určitě by tam byly obrovská množství breaking changes. Zároveň vývojáři Web Forms byli zvyklí mnoho věcí tak trochu hackovat, protože API neumožňovalo vše, co by člověk potřeboval.
Pokud ve svém projektu máte ASP.NET Web Forms, stojíte před složitou volbou – přepsat celou aplikaci, nebo se ji snažit nějak postupně zmodernizovat?
Přepis není často možný vůbec
Mnoho Web Forms aplikací se stále aktivně používá a rozvíjí, a na jejich provozu závisí tisíce firem. Mnoho z těchto aplikací vznikalo více než deset let a lze tedy jen těžko věřit, že je možné je kompletně přepsat v nějakém rozumném čase.
Tým, který se o původní aplikaci stará a rozvíjí ji, má většinou plné ruce práce a bude mít poměrně velký problém vyčlenit dostatek času na vývoj úplně nové verze. Bude tedy třeba tým rozšířit, nebo najmout druhý, což ale znamená zásadní zvýšení nákladů, a vůbec samotné předání know-how a potřebných znalostí novým lidem zabere mnoho času.
Management je navíc často alergický na slovo “přepsat” – do stávající aplikace se nainvestovalo mnoho prostředků a pro project ownera bývá často v podstatě nemožné prosadit, aby se aplikace zahodila a začalo se znovu.
Postupná modernizace
Pokud jste dospěli k tomu, že aplikaci přepsat nemůžete, nezbývá než vymyslet způsob, jak začít s co nejmenším úsilím implementovat novou verzi a provozovat ji souběžně se stávající aplikací – tak, aby některé stránky běžely již v nové verzi, zatímco zbytek bude žít ještě ve staré. Uživatele je třeba nějak rozumně (ideálně se sdílenou autentizací) přesměrovávat mezi starou a novou aplikací.
Dobře byl tento postup vidět donedávna na Azure Portalu. Ve chvíli, kdy Microsoft spustil novou verzi portálu, šlo v ní provádět jen poměrně málo funkcí. Zbytek byl dostupný jen ve starém portálu a trvalo několik let, než se podařilo starý portál úplně zaříznout.
Stará a nová aplikace – možné, ale pracné
Pokud si vyberete některou z moderních JavaScriptových knihoven (nebo se odvážně vrhnete na Blazor, který je ovšem zatím v hodně raném stádiu vývoje), budete muset vedle stávající aplikace vytvořit druhou. Integrovat ASP.NET Core a starou pipeline v jedné aplikaci dost dobře nejde. Dvě aplikace s sebou nicméně nesou několik komplikací:
- Bude třeba vyřešit sdílení autentizační cookie (která má v .NET Core jiný formát).
- Pokud použijete klientskou technologii (Angular, React, Blazor na web assembly), budete muset business logiku nějak na klienta zpřístupnit, například ve formě REST API, nebo třeba Graph QL. Ve Web Forms (nebo v MVC) se k databázi dalo přistupovat napřímo (samozřejmě ne z code behindu nebo contelleru, ale ideálně prostřednictvím nějaké business vrstvy), jenže pokud běžíte na klientovi, musíte přes API.
- Pokud jste používali session a chcete v tom pokračovat (což moc nedoporučuji), bude třeba vymyslet způsob, jak ji nasdílet i do nové aplikace, a to nebude tak jednoduché.
- No a samozřejmě budete muset postupně přepsat všechny ASPX stránky – tomu se vyhout nedá.
Potíž dvou aplikací vidím v tom, že vystrčení business logiky ven pomocí REST API může znamenat velké zásahy do samotné business vrstvy. Bude nějak potřeba vyřešit filtrování, stránkování a řazení dat na klientovi – klient musí nějak serveru poslat informace o filtrech, o aktuální stránce a o sloupečku, podle kterého se řadí, a server to bude muset promítnout do databázového dotazu.
Validace bude třeba také řešit jak na klientské straně, tak na serveru, což v případě JS frameworků znamená duplikování business logiky. A narazíte i na další podobné libůstky, jako formátování čísel a datumů, timezone handling při přenosu dat prostřednictvím JSONu a tak dále.
Tato metoda je tedy možná, ale kromě samotného přepsání ASP.NET stránek do novější technologie jsou nutné i další a relativně velké zásahy do celé aplikace, a pokud použijete Angular nebo React, znamená to naučit se relativně dost nových věcí – JavaScript, mnoho různých knihoven a nástrojů kolem nich. To může zabrat další měsíce času.
Modernizace pomocí DotVVM
DotVVM bylo od začátku zamýšleno jako knihovna, která bude fungovat jak na klasickém ASP.NET, tak i na novém ASP.NET (které bylo v době vzniku DotVVM ještě v plenkách a jeho podoba známá nebyla, jen jsme tušili, že něco takového přijde). Díky tomuto faktu máme unikátní možnost využít DotVVM právě k modernizaci Web Forms aplikací.
DotVVM je v podstatě jen NuGet balíček, který lze nainstalovat do stávající Web Forms aplikace. Díky balíčku Microsoft.Owin.Host.SystemWeb se tyto technologie zkamarádí – pokud přijde HTTP request, dostane jej nejdříve OWIN pipeline (ve které je DotVVM), která jej může odbavit. Pokud tento request OWIN neošetří, “propadne” do klasické ASP.NET pipeline a chopí se jej ASP.NET Web Forms.
V jednom projektu tak budete moci mít jak nové stránky v DotVVM, tak staré ASP.NET stránky, mezi kterými můžete uživatele přesměrovávat.
Velmi snadno budete moci sdílet CSS styly, obrázky a jakékoliv další assety v aplikaci, a nezmění se ani způsob nasazování aplikace – modernizaci tudíž můžete provádět postupně stránku po stránce, a aplikace bude pořád nasaditelná do produkce.
Single sign-on bude fungovat úplně automaticky, protože OWIN sdílí aktuálního uživatele s klasickou ASP.NET pipeline. Dokonce bude fungovat i ta zatracená session (stejně ale doporučuji zbavit se jí).
Všechny ASP.NET stránky sice stále bude nutné přepsat do DotVVM syntaxe (která naštěstí není zas až tak odlišná a mnoho komponent se jmenuje stejně) a code-behind předělat na viewmodely, nicméně obejde se to bez větších zásahů do business vrstvy (pokud jste teda nepoužívali SqlDataSource). Z viewmodelů můžete volat business vrstvu napřímo, bez nutnosti obalovat ji REST API, což ušetří mnoho práce.
Je důležité si uvědomit, že DotVVM není kouzelná hůlka nebo nějaký wizard, kde kliknete Next, Next, Finish a budete mít ASP.NET Web Forms aplikací na .NET Core. Postupné přepsání všech stránek může trvat několik týdnů až měsíců, nicméně je to možné a díky tomu, že tato metoda není tak pracná jako vývoj druhé aplikace, může to zvládnout i stávající tým.
Zároveň je to příležitost, jak provést v business vrstvě nějaký refactoring, a díky využití vzoru MVVM bude mít každá stránka viewmodel, který je testovatelný. Je to tedy i cesta, jak v mezích zákona zlepšit kvalitu codebase a udělat v projektu trochu pořádek.
No a nakonec, jakmile se zbavíte všech závislostí na ASP.NET Web Forms, bude stačit balíček DotVVM.Owin nahradit za DotVVM.AspNetCore a přemigrovat na .NET Core.
Pokud vás tato metoda zaujala, připravil jsem ukázkový repozitář, kde jsou jednotlivé kroky migrace prezentovány v jednotlivých větvích. Na začátku je čistá ASP.NET Web Forms aplikace, na konci je ta samá aplikace běžící v DotVVM a .NET Core.