Discussion :

[rgamor]

Bonjour,

Après avoir lu cet article se penchant sur le Modèle du design pattern MVC, en le décomposant en plusieurs éléments, une question m'est venu: comment faire la liste d'un modèle (par exemple la liste des posts, dans l'article) si seul le modèle est autorisé accéder la base de données?

Car si l'on créait un contrôleur pour lister l'ensemble des posts, il faudra que celui-ci est accès a la bdd, non?

[rawsrc]

Salut,

J'ai rapidement parcouru sa présentation et je pense qu'il est incomplet. Ce qu'il présente c'est une architecture n-tiers et pas MVC.
Dans son schéma chaque couche ne communique qu'avec celles qui sont directement avoisinantes.
Or le MVC c'est plus ceci :


Pour ta problématique, tu peux tout à fait te créer un objet dans le Modèle qui se chargerait d'extraire la liste de tous les posts. Une fois les données extraites, à la demande du contrôleur, ce dernier les passe à la vue pour la mise en forme. Il est même possible que la vue se charge d'aller récupérer ses données auprès du modèle (plus rare, je l'admets)

[rgamor]

Comment faire pour avoir une indépendance complète entre l'application et le support des données (et donc que seul le modèle est accès au support)?

Faut-il que tous les modèles implémentent une interface avec des méthodes comme save(), delete() et list() ?
Mais que renverrai list()? une liste des id ou une liste d'instances du modèle?
Mais je trouve ça bizarre un modèle dont une de ces méthode renverrai une liste d'instances.

Comment ça se fait habituellement?

[rawsrc]

Comment faire pour avoir une indépendance complète entre l'application et le support des données (et donc que seul le modèle est accès au support)?

Normalement, le modèle doit être le seul à accéder aux données. Dès qu'un objet au sein de l'application a besoin de données, il doit faire appel à une méthode du modèle.
N'oublie pas que le modèle peut être vaste. Il peut très bien se diviser et se sub-divisier afin de satisfaire toutes les formes de demandes (en Core, BackOffice, FrontOffice...). C'est à toi à organiser logiquement ta couche métier.
Généralement chaque brique du modèle sera sur un espace de nom qui lui est propre.

Faut-il que tous les modèles implémentent une interface avec des méthodes comme save(), delete() et list() ?

Surtout pas, c'est beaucoup trop rigide. D'ailleurs tu peux très bien avoir des objets persistants mais avec des actions limitées : suppression interdite par exemple.
Donc une interface trop vaste va être vite problématique.

Mais que renverrai list()? une liste des id ou une liste d'instances du modèle?
Mais je trouve ça bizarre un modèle dont une de ces méthode renverrai une liste d'instances.

Comment ça se fait habituellement?

list() peut te renvoyer un tableau avec les données de ton extraction ou un tableau d'instantces d'un autre objet du modèle. Le modèle peut heureusement faire appel à d'autres parties du modèle.
Bref, tu récupères ce dont tu as besoin pour répondre à ta problématique.
Le modèle peut très bien récupérer des données, les transformer et te les renvoyer transformées. Le modèle doit être souple dans la mesure où c'est cette couche qui encapsule toute la complexité du métier.

Et habituellement, il n'y a pas de recette miracle, tout se discute et en fonction des contraintes tu adaptes.

[rgamor]

Surtout pas, c'est beaucoup trop rigide. D'ailleurs tu peux très bien avoir des objets persistants mais avec des actions limitées : suppression interdite par exemple.
Donc une interface trop vaste va être vite problématique.

Je comprends en quoi c'est trop rigide, pour moi toutes ces méthodes doivent être implémenter, et si la suppression est interdite c'est plus à une couche du genre user control de s'en préoccuper et puis si vraiment t'en veux pas tu la code avec un return false ou une levé d’exception.

Et habituellement, il n'y a pas de recette miracle, tout se discute et en fonction des contraintes tu adaptes.

Y'a bien une technique plus ou moins générique vu le nombre de blog, de forum sur le web qui doivent forcément à un moment afficher une liste d'articles ou de sujets