Flux d'application Ruby on Rails

Une femme travaillant devant un ordinateur utilisant un logiciel pour analyser des données qualitatives.

mihailomilovanovic/Getty Images





01 de 07

Flux d'application Rails

Lorsque vous écrivez vos propres programmes du début à la fin, il est facile de voir contrôle de flux . Le programme commence ici, il y a une boucle là, les appels de méthode sont ici, tout est visible. Mais dans une application Rails, les choses ne sont pas si simples. Quel que soit le type de framework, vous renoncez au contrôle de choses telles que le « flux » au profit d'un moyen plus rapide ou plus simple d'effectuer des tâches complexes. Dans le cas de Ruby on Rails, le contrôle de flux est entièrement géré en coulisses, et tout ce qui vous reste est (plus ou moins) une collection de modèles, de vues et de contrôleurs.

02 de 07

HTTP

HTTP est au cœur de toute application Web. HTTP est le protocole réseau que votre navigateur Web utilise pour communiquer avec un serveur Web. C'est de là que viennent des termes comme 'request', 'GET' et 'POST', ils sont le vocabulaire de base de ce protocole. Cependant, puisque Rails est une abstraction de cela, nous ne passerons pas beaucoup de temps à en parler.



Lorsque vous ouvrez une page Web, cliquez sur un lien ou soumettez un formulaire dans un navigateur Web, le navigateur se connecte à un serveur Web via TCP/IP. Le navigateur envoie ensuite au serveur une 'demande', pensez-y comme un formulaire de courrier électronique que le navigateur remplit pour demander des informations sur une certaine page. Le serveur envoie finalement au navigateur Web une « réponse ». Ruby on Rails n'est pas le serveur Web cependant, le serveur Web peut être n'importe quoi de Webrick (ce qui se passe généralement lorsque vous démarrez un serveur Rails à partir du ligne de commande ) à Apache HTTPD (le serveur Web qui alimente la majeure partie du Web). Le serveur Web n'est qu'un facilitateur, il prend la demande et la transmet à votre application Rails, qui génère la réponse et la renvoie au serveur, qui à son tour la renvoie au client. Donc, le flux jusqu'à présent est:

Client -> Serveur -> [Rails] -> Serveur -> Client

Mais 'Rails' est ce qui nous intéresse vraiment, creusons plus profondément là-bas.



03 de 07

Le routeur

L'une des premières choses qu'une application Rails fait avec une requête est de l'envoyer via le routeur. Chaque requête a une URL, c'est celle qui apparaît dans la barre d'adresse d'un navigateur web. Le routeur est ce qui détermine ce qui doit être fait avec cette URL, si l'URL a du sens et si l'URL contient des paramètres. Le routeur est configuré en config/routes.rb .

Tout d'abord, sachez que le but ultime du routeur est de faire correspondre une URL avec un contrôleur et une action (plus sur ceux-ci plus tard). Et comme la plupart des applications Rails sont RESTful et que les éléments des applications RESTful sont représentés à l'aide de ressources, vous verrez des lignes comme ressources :messages dans les applications Rails typiques. Cela correspond à des URL telles que /messages/7/modifier avec le contrôleur des Postes, le Éditer action sur le poste avec l'ID de 7. Le routeur décide simplement où vont les demandes. Ainsi, notre bloc [Rails] peut être un peu étendu.

Routeur -> [Rails]

04 de 07

Le controlle

Maintenant que le routeur a décidé à quel contrôleur envoyer la requête et à quelle action sur ce contrôleur, il l'envoie. Un contrôleur est un groupe d'actions liées toutes regroupées dans une classe. Par exemple, dans un blog, tout le code permettant d'afficher, de créer, de mettre à jour et de supprimer des articles de blog est regroupé dans un contrôleur appelé 'Post'. Les actions sont tout simplement normales méthodes de cette classe. Les contrôleurs sont situés dans application/contrôleurs .

Supposons que le navigateur Web envoie une requête pour /messages/42 . Le routeur décide que cela fait référence au Poste contrôleur, le Afficher méthode et l'ID de la publication à afficher est 42 , il appelle donc le Afficher méthode avec ce paramètre. La Afficher n'est pas responsable de l'utilisation du modèle pour récupérer les données et de l'utilisation de la vue pour créer la sortie. Donc, notre bloc [Rails] étendu est maintenant :



Routeur -> Contrôleur#action
05 de 07

Le modèle

Le modèle est à la fois le plus simple à comprendre et le plus difficile à mettre en œuvre. Le modèle est responsable de l'interaction avec la base de données. La façon la plus simple de l'expliquer est que le modèle est un simple ensemble d'appels de méthode qui renvoient des objets Ruby simples qui gèrent toutes les interactions (lectures et écritures) à partir de la base de données. Donc, en suivant l'exemple du blog, l'API que le contrôleur utilisera pour récupérer les données à l'aide du modèle ressemblera à quelque chose comme Post.find(params[:id]) . La paramètres est ce que le routeur a analysé à partir de l'URL, Post est le modèle. Cela fait des requêtes SQL, ou fait tout ce qui est nécessaire pour récupérer le billet de blog. Les modèles se trouvent dans application/modèles .

Il est important de noter que toutes les actions n'ont pas besoin d'utiliser un modèle. L'interaction avec le modèle n'est requise que lorsque les données doivent être chargées à partir de la base de données ou enregistrées dans la base de données. En tant que tel, nous mettrons un point d'interrogation après cela dans notre petit organigramme.



Routeur -> Contrôleur#action -> Modèle ?
06 de 07

La vue

Enfin, il est temps de commencer à générer du HTML. HTML n'est pas géré par le contrôleur lui-même, ni par le modèle. L'intérêt d'utiliser un framework MVC est de tout compartimenter. Les opérations de base de données restent dans le mode, la génération HTML reste dans la vue et le contrôleur (appelé par le routeur) les appelle tous les deux.

HTML est normalement généré à l'aide de Ruby intégré. Si vous êtes familier avec PHP, c'est-à-dire un fichier HTML avec du code PHP intégré, alors Ruby intégré vous sera très familier. Ces vues sont situées dans application/vues , et un contrôleur appellera l'un d'eux pour générer la sortie et la renvoyer au serveur Web. Toutes les données récupérées par le responsable du traitement à l'aide du modèle seront généralement stockées dans un variable d'instance qui, grâce à un peu de magie Ruby, seront disponibles en tant que variables d'instance depuis la vue. De plus, Ruby intégré n'a pas besoin de générer du HTML, il peut générer n'importe quel type de texte. Vous le verrez lors de la génération de XML pour RSS, JSON, etc.



Cette sortie est renvoyée au serveur Web, qui la renvoie au navigateur Web, qui termine le processus.

07 de 07

L'image complète

Et voilà, voici la vie complète d'une requête vers une application web Ruby on Rails.



  1. Navigateur Web - Le navigateur fait la demande, généralement au nom de l'utilisateur lorsqu'il clique sur un lien.
  2. Serveur Web - Le serveur Web prend la demande et l'envoie à l'application Rails.
  3. Routeur - Le routeur, la première partie de l'application Rails qui voit la demande, analyse la demande et détermine quelle paire contrôleur/action il doit appeler.
  4. Contrôleur - Le contrôleur est appelé. Le travail du contrôleur consiste à récupérer des données à l'aide du modèle et à les envoyer à une vue.
  5. Modèle - Si des données doivent être récupérées, le modèle est utilisé pour obtenir des données de la base de données.
  6. Vue - Les données sont envoyées à une vue, où la sortie HTML est générée.
  7. Serveur Web - Le HTML généré est renvoyé au serveur, Rails en a maintenant terminé avec la requête.
  8. Navigateur Web - Le serveur renvoie les données au navigateur Web et les résultats sont affichés.