Dois-je utiliser AngularJS et ASP.NET MVC?
J'ai commencé à apprendre AngularJS et ASP.NET MVC, mais je ne sais pas pourquoi les utiliser ensemble dans le même projet?
Ne sont-ils pas tous les deux des frameworks MVC? Dois-je les utiliser tous les deux dans la même application? N'est-ce pas l'un ou l'autre?
Si vous créez une application à page unique (SPA) , vous n'avez probablement pas besoin du "MVC" dans ASP.NET MVC . Les vues, en particulier les vues dynamiques, sont probablement fournies/manipulées côté client. Angular gère cela très bien.
Mais peut-être que vous ne voulez pas d'un SPA 100%. Alors quoi? Imaginez plutôt 10 pages, mais 10 pages qui sont très très dynamiques. Une fois qu'un utilisateur s'est connecté, il y a un petit badge utilisateur dans le coin droit. Ce n'est pas dynamique. Il montre juste quelques astuces comme le "score" de l'utilisateur et son dernier selfie. Vous mettez en cache les astuces afin qu'elles puissent être facilement récupérées. Maintenant, vous pouvez procéder de deux façons. Si vous êtes un puriste MVC côté client, vous récupérez simplement les données du badge après la livraison de la charge utile HTML initiale, comme toutes les autres données. Mais vous n'êtes peut-être pas puriste. Vous êtes peut-être l'opposé d'un puriste. Vous êtes peut-être un impuriste. Ainsi, au lieu de fournir le code HTML initial, de fournir du JavaScript qui sera publié sur votre serveur, publié via JavaScript pour récupérer les données de badge, puis finalement fusionner ces données dans une vue via MVC côté client, vous décidez simplement de fusionner les données déjà dans votre cache dans une vue sur le serveur, puis livrez ce comme HTML initial. Une fois que votre code HTML initial est livré, vous procédez à vos pitreries MVC côté client typiques.
Donc ... MVC sur le serveur et sur le client n'est qu'un moyen pratique d'organiser du code qui était un gâchis en 2001. Vous n'avez pas à choisir l'un ou l'autre. Vous pouvez choisir les deux. Certes, plus vous en faites après la livraison du HTML initial, moins vous avez besoin de MVC côté serveur. Pourtant, il est là pour vous si vous en avez besoin. Par exemple, j'ai travaillé sur une application ASP.NET MVC/Angular où les modèles externes Angular peuvent en fait être .NET MVC ActionResult. Cela signifie que votre contrôleur de serveur peut fusionner des données dans sa vue, les livrer à Angular comme modèle, et le contrôleur d'Angular pourrait alors fusionner ses données dans la vue. Je ne dis pas que c'est une bonne idée, mais cela montre simplement qu'une forme de MVC ne fait pas l'autre obsolète.
En outre, peu importe la façon dont vous déployez Angular, vous aurez besoin d'un moyen de fournir le code HTML initial, les modèles et, surtout, les données. Pourquoi ne pas utiliser une plateforme qui vous facilite la tâche? Il y en a beaucoup, mais .NET MVC n'est pas en reste. Comme je l'ai dit, vous pouvez faire du HTML initial et des modèles externes Angular le résultat d'une action MVC, mais mieux encore, vous pouvez utiliser .NET'S API Web pour fournir L'API Web est aussi délicieuse que la compote d'abricot.
Résumé: MVC n'est qu'un modèle. Vous voudrez peut-être utiliser ce modèle sur un nombre quelconque de couches physiques. Il ne peut pas être utilisé. Utilisez-le librement si cela a du sens. En outre, Angular n'est peut-être pas MVC de toute façon (c'est ce que disent les gens qui se soucient de ces choses), alors n'hésitez pas à l'utiliser avec un outil qui a "MVC" dans le nom. Enfer, même s'il s'agit de MVC, mélangez et assortissez comme vous le souhaitez.
ASP.NET MVC est un framework côté serveur; peu importe quelles bibliothèques JavaScript utilisez-vous. AngularJS est une bibliothèque côté client, peu importe la technologie côté serveur qui alimente le site Web - il peut s'agir de Python, d'ASP.NET MVC ou même du vieux tas de fichiers HTML statiques stockés directement sur le disque.
ASP.NET MVC et AngularJS sont tous deux compatibles, et il existe de nombreux projets qui les utilisent ensemble.
Avez-vous besoin pour utiliser les deux? Pas vraiment. Cela dépend entièrement des besoins de votre projet.
Si votre site Web est dynamique, vous devez utiliser des scripts côté serveur. Vous pouvez utiliser ASP.NET, et le fait que vous utilisez AngularJS ne rendra pas votre code côté serveur plus MVC. Si vous voulez pouvoir structurer votre application côté serveur en MVC, vous choisirez plutôt ASP.NET MVC.
De même, le fait que vous utilisez ASP.NET MVC n'implique rien sur la structure de votre code côté client. Vous pouvez mettre tout votre JavaScript dans un seul fichier sans penser à la structure et en être satisfait (jusqu'à ce que le projet commence à croître). Là encore, AngularJS se présente comme un moyen de structurer votre application côté client.
Note latérale: vous avez marqué votre question ASP.NET MVC 3. À moins que ce soit un projet hérité que vous devez maintenir ou que vous ayez des contraintes spécifiques lors de l'hébergement de l'application sur des serveurs hérités qui n'ont pas été mis à jour au cours des quatre dernières années, vous pouvez utiliser ASP .NET MVC 4 ou 5 à la place.
Si vous utilisez Visual Studio, il existe un nouveau modèle de site Web MVC `` application d'une seule page '' qui comprend angular et les contrôleurs MVC Web Api.
Cela fonctionne bien car votre code côté serveur MVC fournit des points de terminaison json pour le code côté client angular à appeler).
De plus, vous pouvez utiliser les contrôleurs MVC pour servir la ou les vues html de base pour votre application à page unique. cela vous donne la puissance de la génération côté serveur, de l'autorisation, des redirections, du traitement des erreurs, etc.
Souvent, vous souhaiterez une petite quantité de code HTML/javascript généré par le serveur, même sur une seule page, des choses comme les URL de point de terminaison pour différents environnements, différentes langues ou même la page d'authentification étrange qui peut être plus facile à faire côté serveur.
3 ans plus tard, utilisez l'API Web ASP.NET pour servir vos données et Angular (js ou plus récent) pour structurer votre application côté client. Si vous créez un site statique, alors utilisez ASP.NET MVC.