NG est un framework front-end MVVM, idéalement, il permettrait une séparation complète du front-end et du back-end et ne fournirait des API que dans le backend. Le découplage du front-end et du back-end est obtenu. Ce découplage nous permet de développer des applications front-end et back-end indépendantes. La manière dont le navigateur consomme l'API back-end est également adaptée aux appareils mobiles tels que l'iPhone Andoird. Lorsque nous développons des applications front-end, le langage de programmation back-end n'est plus nécessaire, seul HTML/CSS/JS est nécessaire, ce qui est une libération pour la plupart des développeurs front-end.

N'avons-nous pas simplement besoin d'écrire des API en arrière-plan ?

C'est une bonne chose. Et personnellement, je pense que cela ne peut pas être attribué uniquement à Angular, cela a aussi beaucoup à voir avec l'acceptation généralisée des interfaces de style RESTful

Tous les frameworks, conceptions et projets n'ont finalement qu'une seule direction : Laissez chacun se concentrer sur son propre domaine

Avant Angular, il existait également des frameworks front-end pour SPA (Single Page Application), tels que extjs, qui plaçaient également l'intégralité de la couche de vue du côté du navigateur.

La méthode de développement de SPA résout un problème de maintenance très important : Zones sales des modèles front-end et back-end Dans le passé, cette zone nécessitait une maintenance conjointe du front-end et du front-end. fin, mais maintenant ce n'est plus nécessaire. Les ingénieurs back-end ne sont plus nécessaires Participer directementau travail de la couche de présentation

Cependant, comme il n'existe pas de style d'interface largement reconnu, il est toujours inévitable de prendre en compte la couche de présentation lors de la conception de l'interface, ce qui rend sa réutilisation difficile. La situation la plus courante consiste à développer à plusieurs reprises plusieurs sockets pour des ressources back-end similaires, ce qui constitue en fait une perte de temps précieux pour les ingénieurs back-end.

On peut dire que garantir des ingénieurs back-end 只管写接口，只管把接口写好 d'un point de vue technique est une énorme libération de productivité back-end.

Pour y parvenir, il est nécessaire de disposer d'un ensemble de styles d'interface généralement acceptés par le front et le back-end, qui peuvent répondre aux besoins d'accès aux ressources multi-pages et même multi-plateformes, et en même temps avoir une bonne sémantique et une bonne capacité de cache

La réponse est RESTful

Avec l'acceptation généralisée des interfaces de style RESTful, le front-end n'a pas besoin de considérer avec quel back-end coopérer au niveau du framework, tant qu'il accède aux ressources RESTful. Les ingénieurs backend sont complètement découplés de la couche de présentation, que le client utilise angulaire/backbone ou mobile. Écrivez simplement l'interface et écrivez l'interface

Quand chacun se concentre sur son propre domaine, c'est là que la valeur est maximisée

Théoriquement oui,
Si votre application est transformée en SPA, le backend n'a besoin que d'une seule route racine pour afficher la page. Le reste sont des routes API

Mais dans les projets réels, que SPA soit facile à utiliser et qu'il y ait de nombreux pièges, alors il est nécessaire de combiner le routage hybride back-end avec le SPA front-end.

Le backend écrit simplement une API, ce qui ressemble presque à ça