MVC - Comment ça marche dans le monde réel?

Question

J'ai lu beaucoup d'exemples triviaux de calculatrices et de thermomètres, mais je n'arrive pas à faire correspondre le modèle à des applications du monde réel.

Supposons que vous ayez un scénario plus compliqué. Supposons que vous ayez un panier d'achat de site Web qui oblige les utilisateurs à se connecter avant d'ajouter au panier. Tout d'abord, l'utilisateur voit la page du produit (/ product/detail) et clique sur ajouter un élément (/ cart/add/207366). L'utilisateur n'est pas encore connecté, il doit donc se rendre sur la page de connexion (/ user/login), puis, étant intelligent sur le flux, il l'amène à la vue du panier (/ panier/liste). À partir de là, ils peuvent revenir à la page de détail du produit d'origine pour continuer à magasiner.

Disons que nous avons 3 tables de base de données: users, usercart et products. Quel est le/les modèle (s) dans cette situation? Est-ce que tout ce flux serait encapsulé dans la fonction addProductToCartFlow du modèle ShoppingCart? Cela semblerait être un peu brouillon, car il faudrait accéder à la table des utilisateurs pour la connexion/authentification et accéder à la table des produits pour tirer les détails du produit/prix dans le panier.

Au lieu de cela, diriez-vous que le modèle ShoppingCart est AUTONOME et ne concerne que l'ajout d'articles, le retrait d'articles, etc. du panier? La "logique" de l'utilisateur connecté serait alors vérifiée ailleurs: peut-être dans le contrôleur lui-même? Cela rendrait les contrôleurs très BUSY avec un peu de «logique métier», comme vérifier si l'utilisateur est connecté, vérifier si le panier est vide, etc. et le modèle devient juste un joli nom pour la table de base de données.

Ou peut-être, le fait même d'être connecté ou déconnecté fait partie d'un modèle UserAuthentication qui traite de telles fonctions. Ou peut-être avons-nous besoin d'un modèle UserPageState pour nous dire si l'utilisateur devrait être sur une page de connexion, ou une page de panier, ou une page de détail de produit?

Quelle est la meilleure conception MVC pour cette situation à votre avis?

Answer 1

Je vais avoir un modèle pour chaque table dans mes sites simples. Je peux utiliser n'importe quel nombre de modèles dans mes contrôleurs. Dans des exemples plus complexes, où un client et un panier ne sont pas séparés, j'ai un modèle qui les rassemble avec des méthodes qui connaissent les deux tables. Ayez beaucoup de modèles, des contrôleurs très minces et seulement du HTML dans vos vues. Vos contrôleurs devraient avoir beaucoup d'instructions "if" qui obtiennent des résultats des contrôleurs. Vos vues peuvent avoir des «fors» qui boucle et répètent des résultats, mais aucune autre logique. Pas de balises HTML ailleurs que dans vos vues.

Donc, pour répondre à votre question, vous pouvez avoir les modèles suivants

• utilisateurs [entre dans la table des utilisateurs]
• Panier [entrer dans la table de panier]
• table de produits et la table des utilisateurs ]
• produits [obtient dans la table du produit]
• commandes [utilisateurs, des chariots et de table (comme par exemple simpliste de base)]
• PageState un modèle qui permet de suivre vos utilisateurs indiquent dans votre site

Vous avez les contrôleurs suivants

• Panier
• utilisateurs
• produits

Les contrôleurs sont peut-être très longue , mais chaque action est petite, avec un travail spécifique. Je pense que c'est correct d'avoir un contrôleur avec 10 actions, tant que ces actions sont belles et courtes elles-mêmes.

Les modèles que ces actions appellent peuvent être assez longs et doivent généralement prendre en compte la logique métier. J'utilise également des classes auxiliaires pour faire des choses qui ne sont pas de la logique métier, mais qui restent critiques. Pensez comme la sécurité et la validation.

Et tout un lot de vues. Vues pour le panier, pour la boîte de connexion, pour le résumé du produit, le détail du produit, chaque phase de la caisse, le reçu, les vues pour le reçu HTML formaté, la liste des catégories, les menus, les pieds de page. Beaucoup et beaucoup de points de vue.

Vous voudriez avoir une classe d'application que tous vos contrôleurs héritent afin que vous puissiez faire des choses encore et encore.

Vous avez mentionné php, donc vous avez des vues qui composent votre modèle, mais si vous avez fait ASP vous auriez une page maître qui fait des vues partielles. Je ne sais pas exactement ce que vous faites en Ruby ou en Python, mais c'est similaire.

Answer 2

Vos modèles sont, pour l'essentiel, des objets de gestion. Vous aurez ShoppingCarts, les utilisateurs et les articles (probablement un panier par client dans la plupart des cas, mais qui doit dire?). Vous aurez des contrôleurs qui pilotent votre flux - la méthode du contrôleur pour/cart/add/207366 vérifiera si l'utilisateur est autorisé et les transmettra au contrôleur pour/login si ce n'est pas le cas. Le contrôleur de connexion doit être assez intelligent pour renvoyer la bonne information au contrôleur pour/cart/add/207366, qui devrait alors ajouter l'article au panier. Les contrôleurs appellent Cart.AddItem(), mais la logique métier est contenue dans le modèle de panier d'achat - il peut rechercher le prix de l'article, une remise client préférentielle basée sur l'utilisateur, etc. Les contrôleurs ne le font pas. Je sais ou je me soucie de ça. Contrôleurs do besoin de savoir si un utilisateur est connecté (si cela compte pour l'application), car cela affecte leur travail (déterminer ce que View pour rendre). Ils n'ont pas besoin de savoir si un client est préféré, ou en attente de crédit, ou quelles que soient les autres conditions de la logique métier. Tout est géré par les modèles.

Answer 3

Je pense que votre inquiétude au sujet des contrôleurs occupés ne devrait pas être un souci: c'est leur but.Le contrôleur de chariot qui a l'action d'ajout s'appuiera sur le contrôleur des utilisateurs ou sur l'assistant d'authentification pour voir si l'utilisateur est connecté. Les deux réponses ci-dessus l'ont bien saisi.

Aussi, au lieu de créer un autre modèle pour les pages, j'utiliserais simplement une variable de session ou un autre champ dans la table. Un autre modèle va vraiment compliquer les choses, et il ne représente pas vraiment une entité que vous avez besoin de contenir. Quand voyez-vous un besoin pour une pile de pages visitées? Ce n'est vraiment qu'une chaîne de l'URL que l'utilisateur a empruntée pour accéder au formulaire de connexion, que vous pouvez suivre de manière beaucoup moins intensive en code et en mémoire avec les variables de session. Il suffit de vérifier addItem() pour voir si elle est connectée, et si ce n'est pas rediriger vers la page de connexion et de stocker la demande en cours. Ensuite, une fois connecté, vérifiez si la variable de redirection est définie, et si oui, allez-y et réinitialisez-le. Je ne vois pas le besoin de quelque chose de plus complexe que cela.

De plus, il semblerait que votre code pastebin soit CakePHP. Bon choix. Si vous le pouvez, profitez de la console de cuisson et de la génération de code d'échafaudage. Il le fait tellement de travail pour vous, et laisse juste les bonnes choses pour vous.