AngularJS client modèle MVC?

Question

Jusqu'à maintenant, je suis principalement à l'aide de Struts 2, Spring, JQuery pile de technologie pour développer des applications web. Le point est, que mentionné pile utilise côté serveur MVC modèle. Le rôle principal de navigateurs web a été limitée à une demande/réponse de cycle (+ la validation côté client). L'extraction des données, la logique d'entreprise, de câblage et de validation ont été principalement les responsabilités du côté serveur.

J'ai quelques questions au sujet des AngularJS cadre qui ont été produites par les citations suivantes, j'ai lu:

---

À partir de la AngularJS tutoriel:

Angulaire apps, nous encourageons l'utilisation de ce Modèle-Vue-Contrôleur (MVC) modèle de conception pour découpler le code et les préoccupations distinctes.

À partir de la Wikipédia Modèle–vue–contrôleur:

Modèle–Vue–Contrôleur (MVC) est une architecture qui sépare le la représentation de l'information de l'utilisateur de l'interaction avec c'. Le modèle se compose de données d'application et les règles d'affaires, et le contrôleur de médiateur de l'entrée, de le convertir à des commandes pour la modèle ou de la vue

---

AngularJS utilise côté client MVC modèle. Donc je suppose qu'il n'y a pas d'autre option pour inclure une logique de validation aussi pour le côté client d'une certaine façon?

Quelle serait la meilleure façon d'écrire un robuste application AngularJS? MVC côté client et une sorte de MC (modèle, contrôleur) sur le côté serveur?

Ne ce qui signifie que le MODÈLE et le CONTRÔLEUR sont dupliqués (client/serveur)?

Je sais que ma question est quelque peu bizarre, mais je pense que la raison est que je suis en quelque sorte accomodé à l'traditionnels côté serveur modèle MVC. Je suis sûr qu'il y est quelqu'un, qui ont déjà fait la transition.

Answer 1

Pas du tout une question étrange - j'ai essayé de vendre Angulaire pour beaucoup de développeurs java, et ils demandent à ce. J'ai demandé moi-même quand j'étais à apprendre (je suis encore en apprentissage, btw)

Si vous prenez un "classique" de java webapp comme vous l'avez décrit et Angulaire-ize, vous avez à prendre d'abord votre serveur et d'en faire une API RESTful. Supprimer les pages Jsp, etc. C'est en fait la partie la plus difficile, de l'OMI, de l'écriture Angulaire app - l'obtention de l'API REST de droit. Pour moi, l'essentiel pour décider de ce que la logique nécessaire pour aller dans le serveur a été pensée comme un pur de l'api et de l'oubli pour l'instant qu'il aura un front-end.

Cette question m'a vraiment aidé - si quelqu'un tente de sauver une ressource donnée et que la ressource n'a pas de données valides il n'y a aucune extrémité avant de dire d'eux - ils sont frapper l'API directement de l'API doit la rejeter. Ainsi, l'extrémité arrière est responsable de la profondeur de validation. Cela s'applique à votre logique métier. Supposons que quelqu'un est en utilisant simplement l'API, et il deviendra clair que votre serveur doit faire.

Le serveur a besoin aussi de vendre les données en (probablement) au format json (j'utilise Spring MVC + Jackson), il est donc responsable pour exposer le modèle Angulaire, et la communication avec la base de données.

Alors, quel est le MVC puis sur le côté Angulaire?

• Modèle: Les données de l'API REST. Si l'API est distributeur de JSON, ces objets seront déjà de 1ère classe des objets javascript.
• Vue: HTML, et les directives lorsque vous avez besoin de manipuler le DOM
• Contrôleur: (et les services personnalisés que vous avez retiré de votre contrôleurs..)
  • Les requêtes à l'API REST et met de ce qui est nécessaire pour la Vue sur le $scope
  • Fournit des rappels pour des directives pour répondre à des événements qui pourraient alors exiger des appels vers le serveur.
  • Validation: généralement par l'intermédiaire d'un rappel à une directive. Sera susceptible de recouvrir une de la validation que vous avez déjà mis dans le serveur, mais vous ne voulez pas que votre utilisateur à attendre que le serveur pour valider les tout - le client doit savoir quelque chose au sujet de la validation de donner à l'utilisateur une rétroaction immédiate.
  • La logique d'entreprise: à peu près la même histoire que la validation.

Mais pourquoi la duplication de la logique dans le client et le serveur? Surtout parce que vous n'êtes pas à l'écriture d'une application, vous avez écrit deux choses: 1) une API REST qui doit être robuste et utilisable sans un front-end 2) une interface graphique utilisateur qui a besoin de donner une rétroaction immédiate à l'utilisateur et pas nécessairement attendre pour un serveur.

Donc, la réponse à court - obtenir l'API REST droit par oublier qu'il y aura une INTERFACE utilisateur, et ce qui se passe dans Angulaire sera beaucoup plus claire.

Answer 2

Je pense que le terme "logique d'entreprise" est un peu un abus de langage ici. Les "affaires" d'un client app est l'affaire de la manipulation de l'interface utilisateur. Il ne va pas être des choses comme des règles de sécurité et de propriété de la logique ou sensibles à la propriété intellectuelle.

Ainsi, dans Angulaire de la division de l'est (en général):

• Contrôleur (controller): pour manipuler les données (champ d'application) à l'arrière de votre INTERFACE utilisateur.
• Directives : pour configurer le DOM pour communiquer avec le contrôleur via le champ d'application, et pour manipuler le DOM.
• Les modèles (point de vue): assigner des directives aux éléments du DOM.
• Champ d'application (modèle ou viewmodel): pour le transport de données entre toutes les pièces du système.
• Services : Injectable, réutilisable morceaux de code. Généralement pour les dépendances, comme la gestion de l'Ajax, les cookies ou autres I/O.

C'est vraiment presque MVVM et pas de MVC.

Quant à votre "métier" ou de règles... tout ce qui requiert de la sécurité doit toujours être assurée au niveau du serveur.

Answer 3

Il est important de comprendre que, dans certaines versions du modèle MVC, les données ainsi que la logique qui manipule les données résident dans la couche "modèle" (avec le "contrôleur" de la couche ne rien faire, mais la liaison). Dans AngularJS, toutefois, les données ($champ) seul réside dans le "modèle" de la couche, alors que la logique qui manipule les données ($champ) réside dans le "contrôleur" de la couche.

Answer 4

J'aime ce que @Roy TrueLove dit. Mais permettez-moi de dire que c'est la meilleure façon d'utiliser angularjs. Bien sûr, vous avez à apprendre à faire vos demandes de cette façon, si vous voulez obtenir le plus d'avantages de anguleux. Je prie pour être un jour.

Dans le même temps, au cours de votre apprentissage, et lors de votre passage pour bien utiliser angularjs que de votre côté client principal moyen de faire les choses, vous pouvez commencer à l'utiliser pour une petite mission ici et là, et peu à peu s'habituer à elle et à sa façon de penser.

Je vous encourage à progressivement en l'embrassant et aller lentement, lentement mais sûrement, je garantie, c'est sûr.

Angularjs est conçu pour servir de cette démarche, car il peut travailler sur la plus petite tâche aussi bon qu'il peut faire le plus grand. Par exemple, cette première fois, j'ai utilisé angulaire était juste pour montrer les noms de tout les types d'utilisateurs de l'ids.

Answer 5

Je suis d'accord avec les réponses ici. Certains commentaires plus. Lorsque vous écrivez un applicacion, vous devez d'abord se concentrer sur le domaine du problème. Et créer un modèle informatique d'une véritable entreprise. Par exemple, si votre problème de domaine est une boutiques, des exigences que vous avez besoin de modèle peut inclure:

• La carte de crédit doit être valide.
• Si vous payez avec une carte de crédit de marque X, vous recevrez 10% de réduction.
• La boutique panier doit contenir au moins un élément pour effectuer la caisse
• Les articles doivent avoir des actions avant d'autoriser les utilisateurs à ajouter à la boutique panier

La mise en œuvre de ces exigences, le modèle de votre problème de domaine, c'est votre logique métier.

Angulaire est un frontend cadre et des outils. C'est un web frontend. Si vous implémentez cette dans une interface web, vous n'aurez pas l'occasion de réutiliser votre modèle à partir d'autres frontend ou de l'interface, comme un mobile ou une application de bureau. Donc, idéalement, une logique d'entreprise la mise en œuvre doit être découplée de toute infrastructure d'interface utilisateur et découplé de toute persistante cadre également. Ensuite, vous aurez votre les objets de l'interface qui va traiter de l'interface utilisateur des problèmes et communiquer avec votre logique métier des objets. Cela peut être un contrôleur Spring MVC, et/ou Angulaire d'un contrôleur ou d'un service.

Il y a un exemple d'application , vous pouvez prendre un coup d'oeil à, qui suivent les principes mentionnés ici.