AngularJS client modèle MVC?
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é inspirés par les citations suivantes, j'ai lu:
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.
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 de l'application et règles métier,
et le contrôleur de médiateur de l'entrée, de le convertir à des commandes pour la
modèle ou 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.
Vous devez vous connecter pour publier un commentaire.
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 était penser 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 entreprise logique aussi. Supposons que quelqu'un est à l'aide de juste 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?
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:
Donc, 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.
But why the duplication of logic in the client and in the server? Mostly because you're not writing one app, you're writing two independent things: 1) a REST API that needs to be robust and usable without a front end 2) a GUI that needs to give immediate feedback to a user and not necessarily wait for a server. So, short answer - get the REST API right by forgetting that there will be a UI, and what goes into Angular will be much clearer.
Merci!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.
Donc Angulaire de la division de l'est (en général):
C'est vraiment presque MVVM et pas de MVC.
Que pour votre "métier" ou de règles... tout ce qui requiert de la sécurité doit toujours être assurée au niveau du serveur.
Il est important de comprendre que, dans certaines versions du modèle MVC, le 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.
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.
J'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.
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 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.
Je semble avoir de cette question, c'est que certaines organisations engouement pour les nouvelles technologies - "je veux cloud...attendez, je veux léger", il est difficile de justifier qu'il mérite de le passer à un lighther cadre.
Je développe des applications à l'aide de Printemps/JBoss seam/JSF et sur le framework MVC tout le temps. La plupart du temps des scripts java sera en résidence pour la couche de présentation des validations et les principales classes d'action/entités et la logique métier réside dans du code Java. Après quelques éléments de base sur les mains sur Angulaire, j'ai commencé à avoir ce qu'ils voulaient dire par MVC comme ils abstraite d'un autre niveau de la couche de présentation, où nous pouvons avoir nos propres vues et les contrôleurs sur la face avant. Pour répondre à votre question, comme tout le monde le commentaire de la meilleure façon est de le poser sur la couche de présentation.
Comme pour la sécurité point de vue, je crois lourds ou des règles doivent résider sur le côté serveur que nous ne voulons pas exposer au monde. Si la logique commerciale est développée mal, on peut facilement trouver la faiblesse de notre code et de l'exploiter.
Voici ma pensée pour le cadre comme Angulaire est comme une petite boutique/SOHO de manipulation, et ils ont un peu de gens et vraiment efficace et rapide.Ils s'adressent bien pour les clients faisant face à des affaires à la livraison et à la réception des marchandises de manière efficace(REST, JSON). Ils ont désigné des rôles et des tâches, mais certains travailleurs effectuer plus d'un tâches. La boutique est également vulnérable à la voleur ou voleurs comme d'habitude ils n'ont pas de souligner, de haute sécurité.
Que pour le côté serveur framework comme Spring/Struts 2, imaginer une entreprise moderne(CMM Niveau 5) avec différents niveaux de gestion et capables de supporter une plus grande entreprise(lot emplois, services web, entreprise de bus). Ils ne manipulent le client, mais pas directement, passent souvent par l'intermédiaire de courtiers ou même des magasins de détail. Sage de la sécurité d'une société est plus robuste, et souvent des titres sur la porte d'entrée, ou les informations importantes sont protégés dans un coffre-fort(chiffrement/authentification).
Mon approche est toujours l'approche bottom-up. À partir de la Conception de Base de données, bien construits et assimilés tables, procédures stockées, lorsque nécessaire, puis ajouter l'Entité Cadre de la solution ou de l'utilisation ADO.Net si EF est pas une option. Puis de développer la Logique Métier, et les Modèles pour obtenir les données dans et hors de la base de données.
Avec les Modèles établis, nous pouvons maintenant aller de deux routes: Développement MVC Contrôleur et /ou le développement WebAPI contrôleur. Les deux contrôleurs peuvent avoir accès à des Modèles, c'est juste une question de l'instanciation des classes et de l'invocation de méthodes.
Vous avez maintenant la possibilité de définir MVC points de Vue qui sont contrôlés par le contrôleur MVC, ou, entièrement distinct ensemble de pages HTML ou SPA (Single Page Application hébergée sur NodeJS).
Avec le jeu de page HTML, vous aurez besoin d'utiliser WebAPI contrôleurs, avec Get, Post, Put et Delete méthodes, et assurez-vous d'inclure jeton d'avant en arrière pour identifier votre client, et permettre de la SCRO (pour l'Origine de la Croix-Demande)
Avec MVC Vues, vous pouvez identifier vos clients à l'aide du contrôleur d'attributs et /ou des sessions et pas besoin de s'inquiéter à propos de la SCRO, et, vous pouvez même apporter votre point de Vue Fortement Typée, si nécessaire. Malheureusement, si vous avez un ensemble de l'INTERFACE utilisateur, les développeurs, ils auront à travailler sur le même MVC solution.
Dans les deux cas, vous pouvez utiliser AngularJS pour le transport de données dans les deux sens à partir de /vers les contrôleurs.
À mon humble avis, le concept de AngularJS contrôleur n'est pas la même chose avec C# MVC ou C# WebAPI contrôleur. AngularJS contrôleur de la maison, tout le javascript logique ainsi que les appels sur les postes clients via le "ApiFactory", alors que C# contrôleurs ne sont rien, mais les points de terminaison du côté serveur que d'accepter et de répondre à l'INTERFACE utilisateur le demande.