MVC question de conception pour les formulaires

Je développe une application qui a une grande quantité de données de formulaire liées à traiter. J'utilise une structure MVC et toutes les données associées sont représentées dans mes modèles, ainsi que le traitement de la validation des données à partir des soumissions de formulaires. Je suis à la recherche de conseils sur la manière de concevoir mes contrôleurs. En gros, j'aurai un formulaire énorme qui sera divisé en catégories gérables (similaire à une application de carte de crédit) où l'utilisateur progresse dans chaque étape/catégorie remplir les réponses. Toutes ces catégories de formes sont liées à la relation/à l'objet principal, mais pas l'une à l'autre. Est-il plus logique d'avoir chaque sous-formulaire/catégorie comme méthode dans la classe de contrôleur principal (ce qui rendra ce contrôleur assez massif), ou serait-il préférable de séparer chaque catégorie en une sous-classe du contrôleur principal? ? C'est peut-être juste pour la propreté que la deuxième approche est meilleure, mais j'ai du mal à voir une grande différence entre créer une nouvelle méthode pour chaque catégorie (qui communique avec le modèle et produire des erreurs/succès) ou créer un nouveau contrôleur pour gérer la même fonctionnalité.MVC question de conception pour les formulaires

Merci d'avance pour toute indication!

Source

2010-03-24 kenny99

Ma préférence serait de créer un triplet Form-Controller-Model pour chaque formulaire affiché à l'utilisateur. Chaque fois que l'utilisateur clique sur le bouton «Suivant» d'un formulaire, son contrôleur doit communiquer avec le gestionnaire principal qui s'occupe de l'envoi de la demande de soumission au prochain formulaire de la chaîne. Vice verset si le bouton 'Retour' est cliqué. Le dernier formulaire a un bouton 'Terminer' qui ira au gestionnaire et passera les derniers bits d'information. Ceci permettra d'éviter l'héritage, de rendre votre code plus robuste et de tester les formulaires de manière isolée.

Source

2010-03-24 15:50:32

Salutations Boris, cette approche a aussi du sens. J'utilise un ORM, où chaque modèle représente une relation de base de données, cependant, au sein de chaque catégorie/sous-formulaire, j'interagirai probablement avec plus d'un modèle, votre approche serait-elle donc réalisable dans ce cas? Excuses si j'ai mal compris – kenny99

Cheers Kenny, il y a des modèles et des modèles. Le modèle MVC est un objet qui sauvegarde l'état de la vue, c'est-à-dire votre forme. Les modèles dont vous parlez sont des modèles d'objets de domaine du côté de la logique métier de la clôture. C'est comme avoir un magasin. Vous utiliserez différents idiomes pour présenter des produits/services aux clients et autres pour la gestion des stocks et des finances. –

Ma préférence serait de tout garder dans un contrôleur. Il maintient tous les processus pertinents pour remplir l'application/formulaire en un seul endroit, même si je ne suis pas sûr de la façon dont «massif» dont vous parlez. Si vous décidez de le diviser, je ne voudrais pas sous-classer hors du contrôleur principal, mais juste faire une poignée de contrôleurs indépendants, peut-être liés par leur nom pour la facilité d'utilisation sur la route.

Source

2010-03-24 15:44:28

Merci Ryan. Massive a peut-être été une exagération, mais il y aurait probablement une dizaine de catégories/méthodes, donc je commençais à me sentir mal à l'aise de savoir si c'était un mauvais design en stockant tout cela dans un contrôleur - mais comme vous le dites, ça a du sens cela fait partie de la forme unique – kenny99

Les contrôleurs sont censés gérer le travail pour une "chose" - à quel point vous voulez définir ce qui vous appartient. Il y a des avantages et des inconvénients dans les deux directions, mais je ne sais pas s'il y a vraiment une bonne ou une mauvaise façon de procéder. –

MVC question de conception pour les formulaires

Répondre

Questions connexes