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

101

Mon équipe et moi avons reçu un financement pour commencer à développer une application Web au niveau de l'entreprise (je n'entrerai pas dans les détails de ce qu'elle fait). L'application aura de nombreuses pages Web séparées, mais deux de ces pages seront plus ciblées et très lourdes - lourdes comme dans beaucoup d'interactions utilisateur, des modaux qui affichent des données de masse, des connexions Websocket, un chat, etc.

J'ai été affecté à l'architecte en chef sur le projet, donc je fais des recherches sur les derniers frameworks Web. Pour le back-end, nous avons fait quelques tests et avons décidé d'aller avec la plateforme Azure SQL. Jusqu'à présent, j'apprécie les améliorations qui ont été apportées et qui sont en train d'être apportées à ASP.NET avec Core 2.0. Plus précisément le moteur Razor, par rapport aux versions précédentes d'ASP.NET MVC.

Je voulais obtenir des avis d'experts sur le "nouveau" Razor vs Angular / React et autres. Je suis particulièrement préoccupé par la performance. Comment Core 2.0 Razor résiste-t-il aux frameworks de rendu côté client? Les différences sont-elles négligeables? Notre application cible 1 000 000 d'utilisateurs potentiels (environ 100 000 utilisateurs simultanés).

Merci d'avance!

— TchPowDog
source

Avec " nouveau Razor ", vous voulez dire des pages Razor?

— Werner

Alors, lequel avez-vous choisi à la fin et comment ça se passe?

— stt106

Comment êtes-vous arrivé (ou allez-vous) avec ce projet? Je suis dans une situation presque identique à vous maintenant et j'aimerais une mise à jour!

— JLo

Salut JLo et stt106. Désolé, il a fallu si longtemps pour répondre. Nous avons finalement opté pour un front-end angulaire et un backend API ASP.NET Core, utilisant Azure SQL. Cela a très bien fonctionné pour nous jusqu'à présent! J'imagine que React serait un remplaçant similaire à Angular si vous êtes plus à l'aise avec cela. J'ai dû apprendre Angular, ce qui était une transition très facile, et je l'adore maintenant!

— TchPowDog

La comparaison de vitesse entre ASP.Net Core et Angular / React est hors sujet? Il peut y avoir des réponses canoniques à cela. Quant à aujourd'hui, nous avons Core 2.2 et bientôt 3.0.

— MikroDel

Réponses:

Nous avons finalement opté pour un front-end angulaire et un backend API ASP.NET Core, utilisant Azure SQL. Nous avons testé Core Razor et, bien que meilleur que l'ancien Razor, Angular a finalement été beaucoup plus rapide pour nous. En ce qui concerne l'expérience utilisateur, Angular (ou React) est bien supérieur en termes de performances. Les aspects de liaison de modèle d'Angular nous ont semblé être un avantage gigantesque du rendu côté serveur. L'utilisation de Razor (ou du rendu côté serveur en général) se prête cependant à une meilleure intégrité globale en ce qui concerne les données et permet une meilleure transition des données du front-end au back-end. Il existe une véritable déconnexion entre un framework front-end et une API. Toutes les données transmises au serveur doivent être converties en objets typés - cela signifie que vous devez gérer deux ensembles de modèles POCO distincts. Cela peut entraîner des problèmes si les objets serveur et les objets frontaux ne sont pas alignés. Pour le moment, Entity Framework Core n'est pas très mature, nous avons donc des problèmes avec la mise à jour des objets, l'interrogation d'objets, y compris les objets enfants, etc.

Dans l'ensemble, cette configuration a très bien fonctionné pour nous jusqu'à présent! J'imagine que React serait un remplaçant similaire à Angular si vous êtes plus à l'aise avec cela. J'ai dû apprendre Angular, ce qui était une transition très facile, et je l'adore maintenant!

— TchPowDog
source

En ce qui concerne la synchronisation des deux ensembles de modèles POCO, il existe une extension vraiment utile pour VS qui crée des interfaces angulaires à partir de modèles MVC, consultez la machine

— Andy Braham

eh bien, personnellement, si je devais utiliser Angular, j'utiliserais NoSql pour la partie DB.

— Venzentx

Je ne peux pas imaginer sélectionner le rasoir ASP.NET au-dessus de Angular. Dans le passé, ASP.NET donnait du code familier aux développeurs .NET, mais avec RAZOR, la courbe d'apprentissage est plus élevée qu'avec Angular. MVC sépare la logique du HTML.

— Mark

@Mark Je ne crois pas ça. Les pages Razor sont parfaites, en particulier la façon dont elles gèrent la liaison de données. Ils sont tout simplement trop bons. Mais ofcource pour son scénario angulaire est parfaitement adapté.

— Mosia Thabo

@MosiaThabo, Mark ne parle pas de Razor Pages, il parle de Razor. C'est ce à quoi mon OP a fait référence. Dans mon article d'origine, je ne faisais pas référence à Razor Pages (ou maintenant appelé Blazor, je pense). Je parlais spécifiquement du rendu côté client par rapport au rendu côté serveur. Razor Pages est la version Angular / React de Microsoft, que je pense qu'ils considèrent comme nécessaire en raison des avantages que vous avez avec Angular et React.

— TchPowDog

En utilisant Angular / React avec l'API côté serveur:

vous éliminez le processus de génération de HTML côté serveur et vous enregistrez le processeur
api produit une petite charge utile (json) et Razor (html) d'un cours serait beaucoup plus grande en taille, recharges constantes de pleine page et aller-retour de publication. pour que l'api et le spa économisent la bande passante
l'api et le spa peuvent avoir différents scénarios de version, de mise à l'échelle et de déploiement
En utilisant l'API, vous pouvez également prendre en charge l'application mobile et si vous commencez par Razor, vous aurez peut-être besoin d'une API à l'avenir

Mais en utilisant Angular / React, vous devriez vous inquiéter des clients:

le client doit activer javascript
le client doit avoir des navigateurs modernes
le client doit disposer d'un matériel suffisamment puissant
SEO

— Mohsen Esmailpour
source

Je comprends les différences entre les deux cadres, j'étais plus préoccupé par la performance.

— TchPowDog

Le même pipline existe pour les deux mais je ne connais pas de référence pour les pages rasoir. ce lien peut aider - ASP.NET Razor Pages vs MVC: Comment les pages Razor s'intègrent-elles dans votre boîte à outils?

— Mohsen Esmailpour

Razor prend en charge le mobile, les inconvénients qui sont répertoriés n'ont pas vraiment d'importance. Les deux sont rapides à leur manière. Je préfère Angular, mais les deux sont optimisés. Razor optimise le code en n'utilisant pas d'arborescence comme le fait MVC. Angular est côté client, il n'utilise donc pas vraiment d'arborescence, mais optimise également les données HTML dans une certaine mesure.

— Nick Turner

@NickTurner Je l'ai compris comme non seulement la visualisation de la page Web sur votre smartphone, mais aussi une application complète. Par exemple, une application Android, qui pourrait obtenir les données de l'API du serveur inchangé telles quelles, tout en utilisant la fonctionnalité fournie par Android - meilleure prise en charge de l'animation, notifications, messages toast, etc.

— Raphael Schmitz

Je n'ai pas de repères. Mais, j'ai plusieurs projets exécutant JQuery, Razor, .NET MVC (C #), AJAX. Pas à l'échelle que vous abordez.

Conseils .. Assurez-vous de bien réfléchir et de suivre les meilleures pratiques. Pour que les choses restent maintenables, assurez-vous de diviser les contrôleurs, les vues et le modèle en groupes plus petits et significatifs. Quand j'ai commencé, j'ai commis l'erreur de tout mettre dans un seul contrôleur Home et une tonne de vues dans le dossier partagé. C'était bien au début, mais lorsque le fluage des fonctionnalités a commencé, il est devenu un gâchis et difficile de revenir en arrière et de redessiner.

J'utilise également Linq2SQL. J'ai commis l'erreur de créer des modèles pour tout, puis j'ai réalisé que je pouvais simplement renvoyer l'ensemble de résultats de mes requêtes en tant que modèle. duh.

Si vous utilisez .NET MVC et que vous êtes préoccupé par les performances, voici les choses que j'ai rencontrées:

NE renvoyez PAS de vues partielles qui créent de gros blocs de HTML! Assurez-vous de tout minimiser. Débarrassez-vous de tout l'espace blanc. Utilisez des noms d'identification plus petits. Prenez le temps de créer un HTML le plus léger possible. Renvoyez JSON et demandez au client de faire une partie du travail.

Faites attention à la façon dont vous développez votre CSS. N'utilisez pas un tas de styles en ligne, prenez le temps de les incorporer dans des fichiers CSS que vous pourrez minimiser plus tard.

Il en va de même pour votre JS côté client. Il est tentant de placer le JS dans des vues partielles. Gardez les choses organisées.

Le rendu sur IE est horrible. Surtout s'il y a beaucoup d'images. Assurez-vous de compresser les images autant que possible, sans perdre en qualité bien sûr.

— Keith Aymar
source