Modèle MVC du client AngularJS?
Jusqu'à présent, j'utilisais principalement Struts 2, Spring, JQuery pile technologique pour la création d'applications Web. Le fait est que la pile mentionnée utilise le modèle MVC côté serveur. Le rôle principal des navigateurs Web se limitait à un cycle de demande/réponse (+ validation côté client). La récupération des données, la logique métier, le câblage et la validation étaient principalement des responsabilités du côté serveur.
J'ai quelques questions concernant le framework AngularJS qui ont été inspirées par les citations suivantes que j'ai lues:
À partir du Tutoriel AngularJS :
Pour les applications Angular Angular, nous encourageons l'utilisation du modèle de conception Model-View-Controller (MVC) pour découpler le code et séparer les problèmes.
À partir de Wikipedia Model – view – controller:
Model – View – Controller (MVC) est une architecture qui sépare la représentation des informations de l'interaction de l'utilisateur avec elles. Le modèle se compose de données d'application et de règles métier , et le contrôleur sert d'intermédiaire pour la convertir en commandes pour le modèle ou la vue
AngularJS utilise le modèle côté client MVC. Donc, je suppose qu'il n'y a pas d'autre option que d'inclure la logique de validation également du côté client d'une manière ou d'une autre?
Quelle serait la meilleure façon d'écrire une application AngularJS robuste? MVC côté client et une sorte de MC (modèle, contrôleur) côté serveur?
Est-ce à dire que le MODÈLE et le CONTRÔLEUR sont dupliqués d'une manière (client/serveur)?
Je sais que ma question est en quelque sorte bizarre, mais je pense que la raison en est que je suis en quelque sorte habitué au modèle MVC côté serveur traditionnel. Je suis sûr qu'il y a quelqu'un qui a déjà fait la même transition.
Pas du tout une question bizarre - j'ai essayé de vendre Angular à beaucoup de Java et ils demandent cela. Je l'ai posé moi-même quand j'ai apprenais (j'apprends toujours, au fait)
Si vous prenez une application Web conventionnelle Java comme vous l'avez décrite et la dimensionnez de manière angulaire, vous devez d'abord prendre votre serveur et en faire une API RESTful. Supprimez les JSP, etc. . C'est en fait la partie difficile, IMO, de l'écriture d'une application Angular - obtenir l'API REST droite. La clé pour moi de décider quelle logique doit aller dans le serveur était en le considérant comme une pure API et en oubliant pour le moment qu'il aura une interface.
Cette question m'a vraiment aidée - si quelqu'un essaie d'enregistrer une ressource donnée et que cette ressource n'a pas de données valides, il n'y a pas de front end pour leur dire - ils frappent directement l'API, donc l'API doit la rejeter. Ainsi, le back-end est responsable de la validation approfondie. Cela s'applique également à votre logique métier. Supposons que quelqu'un utilise juste l'API et il deviendra clair ce que votre serveur doit faire.
Le serveur doit également vendre des données au format (probablement) json (j'utilise Spring MVC + Jackson), il est donc responsable de l'exposition du modèle à Angular et de la communication avec la base de données.
Alors, quel est le MVC du côté Angular?
- Modèle: Les données provenant de l'API REST. Si l'API vend du JSON, ces objets seront déjà des objets javascript de 1ère classe.
- Afficher: HTML et directives lorsque vous devez manipuler le DOM
- Contrôleur: (et les services personnalisés que vous avez pris en compte dans vos contrôleurs ..)
- Interroge l'API REST et place ce qui est nécessaire pour la vue sur l'étendue $
- Fournit des rappels pour que les directives répondent aux événements qui pourraient alors nécessiter des rappels au serveur.
- Validation: généralement via un rappel à une directive. chevauchera probablement une partie de la validation que vous avez déjà mise dans le serveur , mais vous ne voulez pas que votre utilisateur attende que le serveur valide tout - le client doit savoir quelque chose sur la validation pour donner un feedback immédiat à l'utilisateur.
- Logique métier: à peu près la même histoire que la validation.
Mais pourquoi la duplication de la logique dans le client et dans le serveur? Principalement parce que vous n'écrivez pas une application, vous écrivez deux choses indépendantes:
- une REST qui doit être robuste et utilisable sans frontal
- une interface graphique qui doit donner un retour immédiat à un utilisateur et pas nécessairement attendre un serveur.
Donc, réponse courte - obtenez l'API REST juste en oubliant qu'il y aura une interface utilisateur, et ce qui va dans Angular sera beaucoup plus clair).
Je pense que le terme "logique métier" est un peu impropre ici. Le "métier" d'une application côté client consiste à gérer l'interface utilisateur. Ce ne sera pas des choses comme les règles de sécurité et la logique propriétaire ou toute autre propriété intellectuelle sensible.
Donc en Angular la division est (généralement):
- Contrôleur (contrôleur): pour manipuler les données (portée) derrière votre interface utilisateur.
- Directives: pour configurer le DOM pour communiquer avec le contrôleur via la portée, et pour manipuler le DOM.
- Templates (view): Pour assigner des directives aux éléments du DOM.
- Scope (modèle ou modèle de vue): pour transporter des données entre toutes les pièces du système.
- Services: bits de code injectables et réutilisables. Généralement pour les dépendances telles que la gestion d'Ajax, des cookies ou d'autres E/S.
C'est vraiment presque MVVM et non MVC.
Quant à votre logique ou vos règles "métier" ... tout ce qui nécessite une sécurité doit toujours être sécurisé au niveau du serveur.
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 toutes deux dans la couche "modèle" (avec le " contrôleur "couche ne faisant que relier). Dans AngularJS, cependant, les données ($ scope) seules résident dans la couche "modèle", tandis que la logique qui manipule les données ($ scope) réside dans la couche "contrôleur".
Je suis d'accord avec les réponses ici. Encore quelques commentaires. Lorsque vous écrivez une application, vous devez d'abord vous concentrer sur le domaine problématique. Et créez un modèle logiciel d'une entreprise réelle. Par exemple, si votre domaine problématique est un magasinage, certaines exigences que vous devez modéliser peuvent inclure:
- La carte de crédit doit être valide.
- Si vous payez avec une carte de crédit de marque X, vous bénéficierez d'une remise de 10%.
- Le panier de la boutique doit contenir au moins un article pour effectuer le paiement
- Les articles doivent être en stock avant de permettre aux utilisateurs de les ajouter au panier de la boutique
La mise en œuvre de ces exigences modélisera votre domaine de problème, c'est votre logique métier.
Angular est un framework et une boîte à outils frontaux. C'est un frontend web . Si vous l'implémentez dans une interface Web, vous raterez l'occasion de réutiliser votre modèle à partir d'une autre interface ou interface, comme une application mobile ou de bureau. Donc, idéalement, votre implémentation de la logique métier doit être découplée de tout cadre d'interface utilisateur et découplée de tout cadre persistant également. Ensuite, vous aurez vos objets d'interface qui traiteront les problèmes d'interface utilisateur et communiqueront avec vos objets de logique métier. Il peut s'agir d'un contrôleur Spring MVC et/ou d'un contrôleur ou service Angular.
Il y a un exemple d'application que vous pouvez consulter, qui suit les principes mentionnés ici.
J'adore ce que dit @Roy TrueLove. Mais permettez-moi de dire que c'est la façon ultime d'utiliser angularjs. Bien sûr, vous devez apprendre à faire vos applications de cette façon, si vous voulez tirer le meilleur parti de l'angulaire. Je prie d'être là un jour.
Pendant ce temps, pendant votre apprentissage et pendant votre transition vers l'utilisation complète d'angularjs comme principale façon de faire côté client, vous pouvez commencer à l'utiliser pour une petite mission ici et là, et vous y habituer progressivement et à sa manière de en pensant.
J'encourage à l'embrasser progressivement et à y aller lentement lentement, mais sûrement, je le garantis, bien sûr.
Angularjs est conçu pour servir cette approche, car il peut travailler sur la plus petite tâche aussi bien que sur la plus grande. Par exemple, cette première fois, j'ai utilisé angular était juste pour afficher les noms pendant que l'utilisateur tape les identifiants.
Il semble que je me pose également cette question, car certaines organisations ont simplement envie de nouvelles technologies - "Je veux le cloud ... attendez, je veux léger", il est difficile de justifier s'il mérite le passage à un cadre plus léger.
Je développe des applications web en utilisant Spring/JBoss seam/JSF et sur MVC framework tout le temps. La plupart du temps, les scripts Java résideront pour les validations de la couche de présentation et les principales classes d'action/entités et la logique métier résideront dans Java code. Après quelques notions de base) pratique Angular, j'ai commencé à comprendre ce qu'ils voulaient dire par MVC en résumant un autre niveau sur la couche de présentation, où nous pouvons avoir nos propres vues et contrôleurs sur le front-end. Pour répondre à votre question, tout comme tout le monde commente le mieux est de le poser sur le calque de présentation.
En ce qui concerne le point de vue de la sécurité, je pense que les règles métier lourdes ou sensibles devraient résider côté serveur car nous ne voulons pas l'exposer au monde. Si la logique métier est mal développée, on peut facilement trouver la faiblesse de notre code et l'exploiter.
Voici ma pensée pour un cadre comme Angular est comme un petit magasin/client de gestion SOHO, et ils ont quelques personnes et vraiment efficace et rapide. Ils s'adressent bien aux clients confrontés à des affaires et à la livraison/réception de marchandises efficacement (REST, JSON). Ils ont des rôles et des tâches désignés, mais certains travailleurs effectuent plus qu'une tâche. La boutique est également vulnérable aux voleurs ou aux voleurs, car ils n'insistent généralement pas sur une sécurité élevée.
En ce qui concerne le framework côté serveur comme Spring/Struts 2, imaginez une entreprise moderne (CMM niveau 5) avec un niveau de gestion différent et capable de gérer des affaires plus importantes (travaux par lots, services Web, bus d'entreprise). Ils traitent les clients, mais pas directement, passent souvent par des courtiers ou même des magasins de détail. Sur le plan de la sécurité, une entreprise est plus robuste et, souvent, des titres sont à la porte d'entrée ou des informations importantes sont protégées dans un coffre-fort (cryptage/ouverture de session).
Mon approche est toujours l'approche ascendante. À partir de la conception de la base de données, avec des tables correctement construites/associées, des procédures stockées si nécessaire, puis ajoutez Entity Framework à la solution ou utilisez ADO.Net si EF n'est pas une option. Ensuite, développez la logique métier et les modèles pour entrer et sortir les données de la base de données.
Une fois les modèles établis, nous pouvons désormais emprunter deux voies: développer le contrôleur MVC et/ou développer le contrôleur WebAPI. Les deux contrôleurs peuvent avoir accès aux modèles, il s'agit simplement d'instancier les classes et d'appeler les méthodes.
Vous avez maintenant la possibilité de configurer des vues MVC contrôlées par le contrôleur MVC, ou un ensemble entièrement séparé de pages HTML ou SPA (application monopage hébergée sur NodeJS).
Avec l'ensemble de pages HTML entièrement distinct, vous devrez utiliser des contrôleurs WebAPI, avec les méthodes Get, Post, Put et Delete, et assurez-vous d'inclure des jetons dans les deux sens pour identifier votre client et activer CORS (pour Cross Origin Request )
Avec les vues MVC, vous pouvez identifier vos clients à l'aide des attributs de contrôleur et/ou des sessions, sans avoir à vous soucier de CORS, et vous pouvez même rendre vos vues fortement typées si nécessaire. Malheureusement, si vous avez un ensemble de développeurs d'interface utilisateur, ils devront travailler sur la même solution MVC.
Dans les deux cas, vous pouvez utiliser AngularJS pour transporter des données dans les deux sens depuis/vers les contrôleurs.
À mon humble avis, le concept de contrôleur AngularJS n'est pas le même avec le contrôleur C # MVC ou C # WebAPI. Le contrôleur AngularJS héberge toute la logique javascript ainsi que les appels aux points de terminaison via "ApiFactory", tandis que les contrôleurs C # ne sont rien d'autre que des points de terminaison côté serveur qui acceptent et répondent aux demandes de l'interface utilisateur.