ASP.NET Core 2.0 Razor vs Angular / React / etc
Mon équipe et moi avons reçu des fonds pour commencer à développer une application Web de niveau entreprise (sans entrer dans les détails de ce qu'elle fait). L'application comportera de nombreuses pages Web distinctes, mais deux de ces pages seront plus ciblées et très lourdes - lourdes comme dans beaucoup d'interactions utilisateur, les modaux affichant des données en masse, les connexions Websocket, le chat, etc.
J'ai été affecté à l'architecte en chef du projet et je suis donc en train de faire des recherches sur les derniers cadres Web. Pour le back-end, nous avons effectué des tests et décidé d'utiliser la plate-forme Azure SQL. Jusqu'à présent, j'apprécie les améliorations qui ont été apportées à ASP.NET avec Core 2.0 et qui sont en train de l'être. Plus précisément, le moteur Razor, par rapport aux versions précédentes de ASP.NET MVC.
Je voulais obtenir des avis d’experts sur le "nouveau" rasoir contre angulaire/réactif, etc. 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 un million d'utilisateurs potentiels (environ 100 000 simultanés).
Merci d'avance!
Nous nous sommes retrouvés avec un Angular front-end et un backend ASP.NET Core API, en utilisant Azure SQL. Nous avons testé Core Razor et, bien que meilleur que son prédécesseur, Angular était bien plus rapide pour nous à la fin. En ce qui concerne l'expérience utilisateur, Angular (ou React) est de loin supérieur en termes de performances. Les aspects de Angular liés au modèle constituent 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 toutefois à une meilleure intégrité globale en ce qui concerne les données et permet une meilleure transition des données de front-end à back-end. Il existe une véritable déconnexion entre une infrastructure frontale 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 jeux 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 développé, nous avons donc des problèmes avec la mise à jour des objets, leur interrogation, 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 remplacement similaire à Angular si vous êtes plus à l'aise avec cela. J'ai dû apprendre Angular, ce qui était une transition très facile, et j'adore ça maintenant!
En utilisant Angular/React avec api côté serveur:
- vous éliminez le processus de génération de code HTML côté serveur et vous enregistrez le processeur
- api produit une petite charge utile (json) et Razor (html) d’un cours aurait une taille beaucoup plus grande, des rechargements constants d’une page complète et un aller-retour postback. alors api et spa économiser de la bande passante
- api et spa peuvent avoir différents scénarios de version, de dimensionnement et de déploiement
- En utilisant api, vous pouvez également prendre en charge l'application mobile et si vous démarrez par Razor, vous aurez peut-être besoin d'api à l'avenir.
mais en utilisant Angular/React, vous devriez vous inquiéter de vos clients.
- le client doit activer javascript
- le client doit avoir des navigateurs modernes
- le client doit avoir assez de matériel puissant
- SEO
Je n'ai pas de points de repère. 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 tout soit maintenable, veillez à diviser les contrôleurs, les vues et les modèles 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 dans 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 désordre et il est difficile de revenir en arrière et de redessiner.
J'utilise aussi 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 problèmes que j'ai rencontrés:
NE retournez 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 code HTML aussi léger que possible. Renvoyez JSON et demandez au client d'effectuer une partie du travail.
Faites attention à la façon dont vous développez votre CSS. N'utilisez pas de styles en ligne, prenez le temps de les incorporer dans des fichiers CSS que vous pourrez ensuite réduire.
Il en va de même pour votre client JS. 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 de la qualité bien sûr.