ASP.NET, coś innego niż "state of art"

1

Cześć

Zacząłem właśnie naukę "Web Pages" z użyciem "Razor Pages". Jak pouczę się podstaw to zamierzam połączyć ją z jakąś Bazą Danych (podstawy języka SQL już znam). Dalej będzie chciał nauczyć się MVC... i tutaj pojawia się moje pytanie...

Samo środowisko ASP.NET tworzy strony internetowe (web dev) w trzech frameworkach:

  • Web Pages (Razor Syntax) - polecane dla początkujących
  • Web Form - już rzadko stosowane
  • MVC - zaawansowana technologia stosowana, w większości przypadków, w biznesie, ale zalecana dla midów

I pytanie, ASP.NET Core a ASP.NET Standard bardzo się różnią przy tych frameworkach? jak ma się "Core" do "Standard"? Czyli jeśli nauczę się MVC w technologii "Standard" to "Core" dość dużo zmienia i będę musiał na nowo dużo się nauczyć (nie żeby nauka była tutaj "problemem", po prostu pytam o to, jak duży jest wpływ jednego na drugie) ?
Mógłby ktoś podrzucić jakieś dodatkowe informacje o samym Web Pages? Nie chodzi mi o kod i jak zrobić to czy tamto, tylko o genezę, historię. Skąd to się wzięło, albo dla czego coś robimy tak. Myślę, że łatwiej mi będzie programować niż "klepać kod" mając większe zrozumienie całości "jako takiej".

2

.NET Web Form i ASP.NET Framework nie są już rozwijane. ASPNET Core natomiast tak.

Choć wydaje mi się, że jak ogarniesz sobie ASP.NET Framework to poradzisz sobie też później z ASPNET Core, jedynie byś miał do doczytania / wyszukania sobie kilku nowych rzeczy. Ale w sumie po co?

1
Web Pages (Razor Syntax) - polecane dla początkujących
Web Form - już rzadko stosowane
MVC - zaawansowana technologia stosowana, w większości przypadków, w biznesie, ale zalecana dla midów

Nie do końca zgadzam się z tymi definicjami. Ogólnie to radził bym zacząć od MVC bo siłą rzeczy wystawi Cię na wszelkie zagadnienia związanie z używaniem razora, pisanie API, routing itp. Wtedy nauka Pages będzie tylko formalnością. Poza tym pominąłeś jeszcze nowa technologię pozwalającą pisać SPA (Single Page Application) czyli Blazor.

Co do zagadnienia "stary" ASP vs Core to oczywiście lepiej uczyć się Core bo jest nowszy, szybszy, lżejszy, wygodniejszy w obsłudze, wieloplatformowy i ogólnie jest tym w co MS teraz idzie.

A pytania filozoficzne typu po co i dla czego bym sobie raczej odpuścił na tym etapie. Tak, najpierw klep kod a zrozumienie po co i dla czego samo później przyjdzie.

0
Aventus napisał(a):

...Poza tym pokonałeś jeszcze nowa technologię pozwalającą pisać SPA (Single Page Application) czyli Blazor.

Temat Blazora pojawia się co jakiś czas. Tak z ciekawości, czy komercyjnie ktoś w nim robi? Z tematów o nim wywnioskowałem, że Blazor jest dla ludzi którzy nie chcą/lubią frontendowych frameworków. Dla kogo tak naprawdę jest Blazor?

3
gornada napisał(a):

Cześć

Zacząłem właśnie naukę "Web Pages" z użyciem "Razor Pages". Jak pouczę się podstaw to zamierzam połączyć ją z jakąś Bazą Danych (podstawy języka SQL już znam). Dalej będzie chciał nauczyć się MVC... i tutaj pojawia się moje pytanie...

Tak mnie trochę negatywnie piknęło, i miga pomarańczowa lampka.
Framework webowy bez DOBRZE znanego i płynnie używanego języka, to zrobi krzywdę. Tak samo jak w Javie poznawanie Springa przed dobrą znajomością Javy, uczy wyłącznie kalekiego kopiowania i próbowania.

Najbardziej "miganie lampki" mi dało wymienienie (podstaw) SQL-a w jednym zdaniu z technologią widoku - dla mnie wskazówka, ze nie masz dobrych wzorców.

Powinieneś język i wszystkie ważne rzeczy obiektówki używać na tyle płynnie, aby dziwolągi nie zachwiały twojej pewności kroczenia po drodze dobrego projektu.

2

@bakunet: całkiem niedawno z ciekawości wyszukiwałem na LinkedIn oferty pracy gdzie wymieniony był Blazor (na rynku UK). Pojawia się ich coraz więcej ale oczywiście nadal nie jest ich zbyt wiele. Co zrozumiałe- Blazor ma ogromną konkurencję w postaci dużych frameworków/bibliotek JS. Na dodatek nadal jest w fazie wczesnego rozwoju, pomimo że jest już oficjalnie wersją produkcyjną.

Z tematów o nim wywnioskowałem, że Blazor jest dla ludzi którzy nie chcą/lubią frontendowych frameworków. Dla kogo tak naprawdę jest Blazor?

To błędny wniosek bo Blazor sam przecież jest frameworkiem frontendowym (mówię oczywiście o Blazor WebAssembly). Blazor tak naprawdę ma 2 "strategiczne" cele- trafić w pierwszej kolejności do developerów którzy już znają/chcą używać C# (oraz .Net) do pisania kodu frontend, ale drugim celem jest dalszy rozwój tej technologii tak aby można było ją używać do rozwoju innych aplikacji, mobilnych (coś jak React Native) i desktopowych (coś jak Electron).

Mi Blazor bardzo odpowiada bo jestem programistą full-stack, przez ostatnie kilka lat we froncie pracowałem z React oraz Vue i o ile to są spoko technologie to ja szczerze nie znoszę JS. Tu już nawet nie chodzi o C# tylko ogólnie o moją preferencję to języków silnie i statycznie typowanych. Owszem jest TypeScript ale to nadal nie to samo. No i tutaj z pomocą przychodzi Blazor.

Ale Blazor jako framework sam w sobie ma również kilka fajnych rozwiązań w porównaniu do React czy Vue- super system bindowania, zdecydowanie lepszy od tego co oferuje React i chyba również lepszy od Vue, łatwość używania wbudowanego routera (wystarczy deklaracja @page w komponencie), łatwość deklarowania komponentów (nic nie trzeba eksportować itp). Jeszcze trochę był znalazł takich smaczków. No i do tego dochodzi to że Blazor pozwala na dzielenie bibliotek z serwerem, czyli te same DTO mogą być używane przez frontend jak i backend, co ułatwia integrację i pozwala wykrywać szybciej błędy. Z nowinkami C#9 to się staje jeszcze wygodniejsze.

2
gornada napisał(a):

Czyli jeśli nauczę się MVC w technologii "Standard" to "Core" dość dużo zmienia i będę musiał na nowo dużo się nauczyć (nie żeby nauka była tutaj "problemem", po prostu pytam o to, jak duży jest wpływ jednego na drugie) ?

Nie ma czegoś takiego jak ASP.NET Standard. Jest .NET Standard - taki podzbiór kompatybilny z Core i Framework.
Zgaduję, że ASP.NET Standard nazywasz ASP.NET Framework?
Ogólnie, to jest to prawie to samo, w Core po prostu pewne rzeczy zostały uproszczone i więcej jest wbudowanych. Ideologicznie to jest to samo, różnice można zobaczyć w dokumentacji do migracji.
Z punktu widzenia zawodowego, to zależy gdzie się trafi. Dużo nowego softu powstaje w Core, ale jest też dużo do utrzymania we Frameworku.
No i nowa wersja Core nie ma już Core w nazwie - tak, żeby było trudniej. ;)

1 użytkowników online, w tym zalogowanych: 0, gości: 1