ASP.NET Core 2.0 Razor vs Angular / React / etc


101

Mój zespół i ja otrzymaliśmy fundusze na rozpoczęcie tworzenia aplikacji internetowej na poziomie przedsiębiorstwa (nie będę wchodzić w szczegóły tego, co robi). Aplikacja będzie miała wiele oddzielnych stron internetowych, ale dwie z nich będą bardziej skoncentrowane i bardzo ciężkie - ciężkie, jak w przypadku wielu interakcji z użytkownikami, modały wyświetlające masowe dane, połączenia sieciowe, czat itp.

Zostałem przydzielony do projektu Głównego Architekta, więc badam najnowsze frameworki internetowe. Jeśli chodzi o zaplecze, przeprowadziliśmy testy i zdecydowaliśmy się na platformę Azure SQL. Jak dotąd podoba mi się ulepszenia, które zostały wprowadzone i są wprowadzane w ASP.NET z Core 2.0. W szczególności aparat Razor, w stosunku do poprzednich wersji ASP.NET MVC.

Chciałem uzyskać opinie ekspertów na temat „nowego” Razor vs. Angular / React i tym podobnych. Szczególnie interesuje mnie wydajność. W jaki sposób Core 2.0 Razor radzi sobie ze strukturami renderowania po stronie klienta? Czy różnice są nieistotne? Nasza aplikacja jest przeznaczona dla potencjalnych 1 000 000 użytkowników (około 100 000 jednocześnie).

Z góry dziękuję!


4
Mówiąc „ nowy Razor ” masz na myśli strony Razor?
Werner

36
Więc który z nich ostatecznie wybrałeś i jak leci?
stt106

5
Jak sobie radzisz (lub radzisz sobie) z tym projektem? Jestem teraz w prawie identycznej sytuacji jak Ty i chciałbym zaktualizować!
JLo

10
Cześć JLo i stt106. Przepraszam, że odpowiedź zajęła tyle czasu. Skończyło się na korzystaniu z frontonu Angular i zaplecza interfejsu API ASP.NET Core przy użyciu Azure SQL. Jak dotąd świetnie nam się udało! Wyobrażam sobie, że React byłby podobnym zamiennikiem do Angulara, jeśli czujesz się z nim bardziej komfortowo. Musiałem się nauczyć Angulara, co było bardzo łatwym przejściem i teraz go uwielbiam!
TchPowDog,

Porównanie szybkości ASP.Net Core i Angular / React nie jest tematem? Mogą istnieć kanoniczne odpowiedzi na to pytanie. Na dzień dzisiejszy mamy Core 2.2, a wkrótce 3.0.
MikroDel

Odpowiedzi:


74

Skończyło się na korzystaniu z frontonu Angular i zaplecza interfejsu API ASP.NET Core przy użyciu Azure SQL. Przetestowaliśmy Core Razor i chociaż Angular był lepszy od starszego Razora, ostatecznie był dla nas znacznie szybszy. Jeśli chodzi o wrażenia użytkownika, Angular (lub React) jest znacznie lepszy pod względem wydajności. Okazało się, że aspekty Angulara związane z modelami są gigantyczną zaletą renderowania po stronie serwera. Korzystanie z Razor (lub generalnie renderowania po stronie serwera) zapewnia jednak lepszą ogólną integralność danych i zapewnia lepsze przejście danych z front-endu do back-endu. Istnieje prawdziwy rozdźwięk między frameworkiem frontonu a interfejsem API. Wszystkie dane przekazywane do serwera muszą być rzutowane na obiekty o określonej maszynie - oznacza to, że musisz zarządzać dwoma oddzielnymi zestawami modeli POCO. Może to powodować problemy, jeśli obiekty serwera i obiekty frontonu nie są wyrównane. W tej chwili Entity Framework Core nie jest zbyt dojrzały, więc mamy problemy z aktualizowaniem obiektów, odpytywaniem obiektów, w tym obiektów podrzędnych itp.

Ogólnie rzecz biorąc, jak dotąd ta konfiguracja działała dla nas świetnie! Wyobrażam sobie, że React byłby podobnym zamiennikiem do Angulara, jeśli czujesz się z nim bardziej komfortowo. Musiałem się nauczyć Angulara, co było bardzo łatwym przejściem i teraz go uwielbiam!


5
Jeśli chodzi o synchronizację dwóch zestawów modeli POCO, istnieje naprawdę przydatne rozszerzenie dla VS, które tworzy interfejsy kątowe z modeli MVC, sprawdź maszynę
Andy Braham

cóż, osobiście, gdybym musiał iść z Angularem, użyłbym NoSql dla części DB.
Venzentx

2
Nie wyobrażam sobie wybierania maszynki do golenia ASP.NET powyżej Angular. W przeszłości ASP.NET udostępniał kod znany programistom .NET, ale w przypadku RAZOR krzywa uczenia się jest większa niż przy użyciu Angular. MVC oddziela logikę z kodu HTML.
Mark

1
@Mark Nie wierzę w to. Razor Pages są doskonałe, a konkretnie sposób, w jaki obsługują powiązania danych. Są po prostu zbyt DOBRE. Ale źródło dla jego scenariusza „angular” jest idealne.
Mosia Thabo

2
@MosiaThabo, Mark nie mówi o Razor Pages, on mówi o Razor. Do czego odnosi się mój OP. W moim oryginalnym poście nie odnosiłem się do Razor Pages (lub, jak sądzę, nazywanego teraz Blazor). Mówiłem konkretnie o renderowaniu po stronie klienta vs renderowaniu po stronie serwera. Razor Pages to wersja Angular / React Microsoftu, którą, jak sądzę, uważa za niezbędną ze względu na zalety, jakie daje Ci Angular i React.
TchPowDog

49

Korzystając z Angular / React z API po stronie serwera:

  • eliminujesz proces generowania HTML po stronie serwera i oszczędzasz procesor
  • API generuje mały ładunek (json), a Razor (html) kursu byłby znacznie większy, ciągłe przeładowywanie całej strony i ogłaszanie zwrotne w obie strony. więc api i spa oszczędzają przepustowość
  • API i spa mogą mieć różne scenariusze wersjonowania, skalowania i wdrażania
  • Korzystając z API, możesz również obsługiwać aplikację mobilną, a jeśli zaczniesz od Razor, możesz potrzebować API w przyszłości

Ale używając Angular / React, powinieneś martwić się o klientów:

  • klient musi włączyć javascript
  • klient musi mieć nowoczesne przeglądarki
  • klient musi mieć wystarczająco wydajny sprzęt
  • SEO

1
Rozumiem różnice w tych dwóch ramach, bardziej interesowała mnie wydajność.
TchPowDog

Ta sama linia pipline istnieje dla obu, ale nie wiem, czy istnieje żaden punkt odniesienia dla stron z maszynkami do golenia. to łącze może pomóc - ASP.NET Razor Pages vs MVC: Jak pasują Razor Pages w przyborniku?
Mohsen Esmailpour

1
Razor obsługuje urządzenia mobilne, wymienione wady nie mają znaczenia. Obie są szybkie na swój sposób. Wolę Angular, ale oba są zoptymalizowane. Razor optymalizuje kod, nie używając drzewa, takiego jak MVC. Angular jest po stronie klienta, więc tak naprawdę nie używa drzewa, ale także w pewnym stopniu optymalizuje dane w HTML.
Nick Turner

@NickTurner Zrozumiałem to nie tylko jako przeglądanie strony internetowej na smartfonie, ale jako całkowicie własną aplikację. Np. Aplikacja na Androida, która mogłaby pobierać dane z niezmienionego API serwera w obecnym stanie, z drugiej strony korzystając z funkcjonalności, którą zapewnia Android - lepszej obsługi animacji, powiadomień, wiadomości tostowych itp.
Raphael Schmitz

23

Nie mam wzorców. Ale mam kilka projektów z JQuery, Razor, .NET MVC (C #), AJAX. Nie na skalę, z którą walczysz.

Porady. Pamiętaj, aby przemyśleć wszystko i postępować zgodnie z najlepszymi praktykami. Aby zachować łatwość konserwacji, należy podzielić kontrolery, widoki, model na mniejsze i znaczące grupy. Kiedy zacząłem, popełniłem błąd, umieszczając wszystko w jednym kontrolerze domowym i mnóstwie widoków w folderze współdzielonym. Na początku było dobrze, ale kiedy zaczęło się pełzanie funkcji, stało się bałaganem i trudno było wrócić i przeprojektować.

Używam również Linq2SQL. Popełniłem błąd, tworząc modele dla wszystkiego, a potem zdałem sobie sprawę, że mogę po prostu zwrócić zestaw wyników z moich zapytań jako model. duh.

Jeśli korzystasz z platformy .NET MVC i martwisz się o wydajność, napotkałem następujące rzeczy:

NIE zwracaj częściowych widoków, które tworzą duże bloki HTML! Pamiętaj, aby wszystko zminimalizować. Pozbądź się wszystkich białych znaków. Użyj mniejszych nazw ID. Poświęć trochę czasu, aby stworzyć jak najlżejszy kod HTML. Zwróć JSON i poproś klienta o wykonanie części pracy.

Uważaj na to, jak rozwijasz swój CSS. Nie używaj wielu stylów wbudowanych, poświęć trochę czasu na włączenie do plików CSS, które możesz później zminimalizować.

To samo dotyczy JS po stronie klienta. Kuszące jest umieszczenie JS w widokach częściowych. Utrzymuj porządek.

Renderowanie na IE jest okropne. Zwłaszcza jeśli jest dużo obrazów. Pamiętaj, aby kompresować obrazy tak bardzo, jak to możliwe, oczywiście bez utraty jakości.

Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.