Ruby Forum Rails France > concevoir une application MVC

Bonjour,

J'ai une petite question sur la conception d'un site rails.

Mettons que j'ai une application qui gère une base d'informations sur
les films par exemple. je vais donc avoir des tables qui vont être
directement liées aux vues que je vais proposer, soit en admin, soit en
front. Je vais également avoir des tables qui vont être là pour "faire
le liant" avec les medias ou encore stocker des préférences diverses.

Les tutoriaux sur Rails présentent tous la façon de faire Model >
Contrôleur / Vue, avec une table par modèle. mais que faire quand on a
des tables qui ne sont pas censées être appelées par les urls, qui sont
là pour stocker des données internes et privées ? on crée juste le model ?

Et plus généralement, est ce qu'on peut avoir des Controllers qui
s'occupent de plusieurs Models ? ou l'inverse ?

Merci,

FX

>  J'ai une petite question sur la conception d'un site rails. [...]

Mon grain de sel de débutant, n'hésitez surtout pas à me contredire...

J'ai compris le MVC comme "simplement" (ce n'est pas toujours si
simple) demandant de bien ségréger modèles, vues et contrôleurs. C'est
un exercice que je fais encore : à chaque fois que j'écris ne
serait-ce qu'une seule ligne, je me dis "est-ce un modéle, une vue ou
un contrôleur ?". Et je crois que ça se limite à ça.

Ensuite, ta façon de découper les controleur pour gérer quels modèles
en employant quelles vues c'est déjà autre chose. C'est me semble-t-il
plus une question d'habitude, d'affinité de programmeur.

Bon, ensuite des directives comme REST imposent presque le choix des
contrôleurs, mais c'est pas très gênant.

Voici mes reflexions :
- Modèle : ça traite vraiment des données. Pour moi c'est ce qui est
représenté le plus facilement par le développement objet tel qu'on me
l'a appris à l'école : des données avec des méthodes qui permettent de
les gérer. Par exemple tu auras le film ainsi que la méthode "evaluer"
qui permet de donner une note automatiquement au film en fonction du
budget du film et des recettes (mais c'est débile comme exemple 
ça!!!)
- Vues : tout ce qui concerne les technique d'affichage : le HTML, le
CSS... toute la présentation.
- Contrôleur : il prépare les vues (en calculant les données
nécessaires), et s'occupe des enchaînements des pages.

Pour tout dire, j'ai pas mal de soucis avec les contrôleurs. Quels
contrôleurs ? Qui gèrent quoi ?

Ma façon de voir, c'est de se dire "un contrôleur pour chaque façon
différente d'attaquer mon appli".
Par exemple pour tes films tu peux imaginer l'ultra classique
découpage suivant :
- un controleur d'administration
- un contrôleur pour les utilisateurs
- un contrôleur pour gérer le distributeur automatique de location de
DVD que tu as implanté au bas de chez toi

Tu vois dans ce découpage que chaque contrôleur manipulera différents
modèles, et que de toutes façons la plupart des podèles seront
manipulés par les 3 contrôleurs (un utilisateur s'inscrit sur
Internet, il loue avec ce meme compte un DVD, et toi, l'admin, tu
consulte sa fiche)

Voilà, si j'ai dis une bêtise, dites-le moi !

gUI

--
Pour la santé de votre ordinateur, préférez les logiciels libres.
Lire son mail : http://www.mozilla-europe.org/fr/products/thunderbird/
Browser le web : http://www.mozilla-europe.org/fr/products/firefox/
Suite bureautique : http://fr.openoffice.org/

>> Et plus généralement, est ce qu'on peut avoir des Controllers qui
s'occupent de plusieurs Models ? ou l'inverse

Rien n'interdit de référencer n'importe quel model à partir de n'importe
quelle controller.

En fait, dès qu'on sort de la grossière simplification offerte par les
scaffold, il n'y a pas de relation forte entre table (model) et 
controller.
S'il reste une relation forte c'est entre controller et vues.

>> que faire quand on a des tables qui ne sont pas censées être appelées par
les urls
Attention à la terminologie. Là encore pas de relation directe entre URL 
et
table.

>> on crée juste le model ?
Tout à fait : script/generate model toto

De même on peut tout-à-fait définir un contrôleur sans modèle associé
(script/generate controller titi).

En fait, dans le MVC Rails, c'est le controleur qui "répondra" plus
directement à l'URL.  Il représente en quelque sorte une couche
d'abstraction entre les modèles et le web.

Hope it helps :-)



--
IciMarché fédère l'e-commerce de proximité
http://icimarche.fr

> En fait, dès qu'on sort de la grossière simplification offerte par les
> scaffold, il n'y a pas de relation forte entre table (model) et controller.
> S'il reste une relation forte c'est entre controller et vues.

Ouf, je me sens plus libre maintenant :)

> En fait, dans le MVC Rails, c'est le controleur qui "répondra" plus
> directement à l'URL.  Il représente en quelque sorte une couche
> d'abstraction entre les modèles et le web.

merci pour ces précisions.
Encore une question : pour la page d'accueil, rails indique qu'on la
dirige vers un controller adéquat, seulement en général une page
d'accueil va chercher des infos depuis plein de models...

quelle est la bonne pratique rails pour organiser sa home page ?

Merci,

FX

Je programme déjà en MVC sur d'autres langages, et donc mon hésitation
tournait surtout autour de l'ActiveRecord et des models, qui sont plus
stricts dans Rails que dans un framework développé à usage personnel.
de sorte que pour le moment, mes models sont organisés par segment
applicatif, comme toi les controllers (un model pour l'administration,
un model pour la gestion des dvds, etc).

Ceci dit, récemment je me suis rendu compte que j'étais obligé de
devenir plus strict sur mes modèles et mes controlleurs,
principalement pour une question de référencement : pour faire
remonter des fils d'ariane, des title ou sélectionner des menus en
fonction de votre page, il m'apparaît plus judicieux de faire un
controleur par type de page, ce que Rails pousse à faire.

Mon commentaire par rapport à ta manière de faire, je dirais que ca
risque de pecher un peu justement au niveau de tout ce qui gravite
autour du référecement : tes controlleurs englobent de très grosses
parties de ton site (tout l'admin, toute la gestion de dvds),
j'imagine donc que tu dois avoir pas mal d'actions à l'intérieur de
chaque contrôleur, et donc ca rend le rooting et la localisation
intra-site plus confuse, j'imagine.


Le 28 avril 2008 08:07, Guillaume Betous <guillaume.betous@gmail.com> a 
écrit :
>
>  l'a appris à l'école : des données avec des méthodes qui permettent de
>
>  modèles, et que de toutes façons la plupart des podèles seront
>  Lire son mail : http://www.mozilla-europe.org/fr/products/thunderbird/
>  Browser le web : http://www.mozilla-europe.org/fr/products/firefox/
>  Suite bureautique : http://fr.openoffice.org/
>
>  >
>



--
François-Xavier Guillois
http://www.fxguillois.eu/

>> seulement en général une page d'accueil va chercher des infos depuis
plein de models...

Encore un fois, aucune objection à ça ; on est libre de taper dans tous 
les
modèles à partir de n'importe où.

>> quelle est la bonne pratique rails pour organiser sa home page ?

Je crois deviner ce que tu sous-entends :
On peut aggréger des partials liées à des contrôleurs eux mêmes liés à 
des
vue, mais tout est une simple question de choix d'organisation, il n'y a 
pas
de règle rigide.

--
IciMarché fédère l'e-commerce de proximité
http://icimarche.fr