Je viens d'utiliser ASP.NET MVC / Web API et maintenant je commence à utiliser Angular mais je ne suis pas clair sur la bonne façon de les mélanger.
Une fois que j'utilise Angular, les concepts côté serveur MVC fournissent-ils toujours une valeur? Ou devrais-je utiliser l'API Web uniquement pour obtenir des données pour les appels HTTP angulaires?
Tous les conseils que vous avez pour un gars ASP.NET MVC passant à Angular seraient utiles
Réponses:
API Web pure
J'étais assez hardcore avec ASP.NET MVC mais depuis que j'ai rencontré Angular, je ne vois pas une seule raison pour laquelle j'utiliserais un framework de génération de contenu côté serveur. Pure Angular / REST (WebApi) donne un résultat plus riche et plus fluide. C'est beaucoup plus rapide et vous permet de créer des sites Web assez proches des applications de bureau, sans aucun piratage génial.
Angular a une petite courbe d'apprentissage, mais une fois que votre équipe l'a maîtrisée, vous créerez de bien meilleurs sites Web en moins de temps. Cela a principalement à voir avec le fait que vous n'avez plus tous ces problèmes d'état (moins).
Par exemple, imaginez un formulaire d'assistant avec n'importe quel framework côté serveur traditionnel. Chaque page doit être validée et soumise séparément. Peut-être que le contenu de la page dépend des valeurs d'une page précédente. Peut-être que l'utilisateur a appuyé sur le bouton Retour et soumet à nouveau un formulaire précédent. Où stockons-nous l'état du client? Toutes ces complications n'existent pas lors de l'utilisation de Angular et REST.
Alors ... venez du côté obscur ... nous avons des cookies.
AngularJS est davantage associé au paradigme de l'application à page unique et, en tant que tel, ne bénéficie pas beaucoup des technologies côté serveur qui rendent le balisage. Il n'y a aucune raison technique qui vous empêche de les utiliser ensemble, mais dans un sens pratique, pourquoi le feriez-vous?
Un SPA récupère les ressources dont il a besoin (vues JS, CSS et HTML) et s'exécute de manière autonome, communiquant avec les services pour envoyer ou récupérer des données. Ainsi, une technologie côté serveur est toujours nécessaire pour fournir ces services (ainsi que d'autres moyens tels que l'authentification et autres), mais les parties de rendu sont largement hors de propos et pas particulièrement utiles car c'est une duplication des efforts, sauf que MVC le fait. côté serveur et Angular le fait sur le client. Si vous utilisez Angular, vous le souhaitez sur le client pour de meilleurs résultats. Vous pouvez créer des formulaires HTML de publication angulaire et récupérer des vues partielles des actions MVC, mais vous manqueriez les fonctionnalités les meilleures et les plus simples d'Angular et vous rendriez la vie plus difficile.
MVC est assez flexible et vous pouvez l'utiliser pour traiter les appels d'une application SPA. Cependant, WebAPI est plus finement réglé et un peu plus facile à utiliser pour de tels services.
J'ai écrit un certain nombre d'applications AngularJS, y compris quelques applications qui ont migré à partir d'applications WebForms et MVC préexistantes, et l'aspect ASP.NET évolue vers une plate-forme pour fournir l'application AngularJS en tant que client réel et pour héberger la couche d'application. le client communique avec via REST (en utilisant WebAPI). MVC est un bon framework, mais il se retrouve généralement sans travail dans ce type d'applications.
L'application ASP.NET devient une autre couche de l'infrastructure, où ses responsabilités se limitent à:
Un autre avantage d'un SPA est qu'il peut augmenter la bande passante de votre équipe. Un groupe peut faire exploser les services tandis que l'autre se trouve dans l'application cliente. Étant donné que vous pouvez facilement stub ou simuler des services REST, vous pouvez avoir une application client entièrement fonctionnelle sur des services simulés et remplacer les services réels une fois qu'ils ont terminé.
Vous devez investir d'avance sur Angular, mais cela rapporte gros. Puisque vous êtes déjà familier avec MVC, vous avez une longueur d'avance sur certains des concepts de base.
Cela dépend du projet sur lequel vous travaillez.
Si angularJS est quelque chose de nouveau pour vous, je préférerais choisir un petit projet à faible risque / pression pour commencer et vous assurer d'apprendre à faire les choses de la bonne manière (j'ai vu de nombreux projets utiliser Angularjs mal à cause de la pression, des délais ... manque de temps pour l'apprendre correctement, par exemple en utilisant JQuery ou en accédant au DOM à l'intérieur des contrôleurs, etc ...).
Si le projet est un champ vert et que vous avez une certaine expérience sur AngularJS, il est logique d'abandonner ASP.net MVC et, côté serveur, d'opter pour du REST / WebAPI pur.
S'il s'agit d'un projet existant, vous pouvez choisir un sous-ensemble complexe de fonctionnalités et créer cette page en tant qu'application angularJS distincte (par exemple, votre application est composée d'un grand nombre de pages standard simples / moyennes basées sur Razor mais vous avez besoin d'un éditeur avancé / page, qui pourrait être la pièce cible à construire avec AngularJS).
Vous pouvez utiliser le framework Angular pour le développement frontal, c'est-à-dire pour construire des vues. Il vous offre une architecture robuste et une fois que vous aurez appris, vous trouverez ses avantages par rapport au moteur de vue rasoir d'Asp.net MVC. Pour récupérer des données, vous devez utiliser des WebAPI et maintenant le projet ASP.Net MVC prend en charge les contrôleurs WebAPI et MVC prêts à l'emploi. Vous pouvez consulter le lien ci-dessous pour démarrer le développement d'applications Angular et ASP.Net MVC.
http://hive.rinoy.in/angular4-and-asp-net-mvc-hybrid-application/
Il existe actuellement deux frameworks pour développer des composants d'interface utilisateur pour des applications angulaires. J'ai utilisé ces deux cadres dans l'un des projets angulaires sur lesquels j'ai travaillé.
Matériel https://material.angular.io/