Je concevons un système de gestion de produit. Je me demande la meilleure façon de gérer une grande quantité de variation dans chaque action / vue de ma candidature. L'application gère 20 catégories et 12 marchés cibles, chacun affectant les données à collecter pour chaque produit. Par exemple, l'action "QuickAdd" prend dans les données principales telles que le nom du produit et la SKU, ainsi que de quelques autres informations clés basées sur le combo de la catégorie et du marché cible que le produit est ajouté à (exemples ci-dessous). La catégorie et le marché cible ne sont pas des attributs configurables du produit, l'utilisateur utilisant le système ne peut fonctionner que sous un combo particulier, par exemple des jouets / États-Unis. La raison de la mention de ce que je ne peux pas concevoir le formulaire pour avoir des sections d'attributs pour chaque combo de catégorie / marché, il doit fonctionner comme le formulaire de cette catégorie / marché - l'utilisateur n'a aucune connaissance d'autres combos. p>
Quelques exemples à clarifier espérons que les situations possibles: p>
Si j'ajoute un produit à la catégorie Jouets avec le marché cible des États-Unis dont j'ai besoin demander la "période d'âge" et "a fait Il passe l'inspection de la sécurité ". P>
Si j'ajoute un produit à la catégorie Jouets avec marché cible mexico, je viens de besoin de demander "la plage d'âge". p>
Si j'ajoute un produit à la Catégorie Vêtements avec la cible Market USA, je dois demander le "Style" et "matériau" p>
Si j'ajoute un produit à la Catégorie Vêtements avec la cible Market Canada, je dois demander le "Style" et "Matériel" et "Prix USA" P>
Nous avons 20 catégories et 12 cible Marchés, plus il y a 10 formes que besoin de se comporter de cette manière, donc théorie il y a 2400 distincts Actions / Vues / Modèles P> blockQuote>
La question est donc, dans ASP.NET MVC, quelle est la meilleure façon de gérer l'affichage de toutes ces formes dynamiques et de gérer les variations de données envoyées à l'action? P>
éditer strong>
Une clarification sur la manière dont les attributs du produit sont déterminés: ils sont basés sur la hiérarchie du produit appartenant à une catégorie sur un marché. Par exemple, ce n'est pas l'ajout de tous les attributs de jouets et les attributs américains que nous demandions, ce sont les attributs d'un produit qui est un jouet vendu sur le marché américain. Un jouet vendu aux États-Unis a besoin de l'information "Inspection de sécurité", mais les vêtements aux États-Unis ne le font pas. Un jouet au Mexique n'a pas non plus besoin de l'information "Inspection de sécurité", de sorte que l'attribut ne soit pas inhérent à tous les jouets ou à tous les produits USA, mais plutôt le fait qui est un combo de catégorie et de marché. P>
4 Réponses :
Je créerais des modèles de domaine pour les types d'attributs.
public static string RenderAttribute(this HtmlHelper, ICategoryAttribute att)
{
StringWriter stringWriter = new StringWriter();
using (HtmlTextWriter writer = new HtmlTextWriter(stringWriter))
{
switch(att.AttributeType)
{
case AttributeDataType.Boolean:
CreateCheckBox(writer, att);
break;
case AttributeDataType.List:
CreateListBox(writer, att);
break;
// Other types
}
}
stringWriter.ToString();
}
Je serais curieux de voir comment vous géreriez les données après son envoi à l'action.
J'aime l'approche générale en termes de traitement de la vue. Couple Points: La catégorieAttributices ne doit-elle pas aussi prendre une zone de tabise? Aussi, je pense que la signature d'action ressemblerait plus à Public ActionResult Quickadd (int CatégorieId, int CatégorieTrid, Nom de la chaîne, SCHU, iNeumable attributs code> devrait être défini avec un classeur de modèle. En fait, un groupe de paramètres pourrait être déployé dans un paramètre de produit à l'aide de la liaison de modèle.
Vous auriez besoin de la zone tacheté mais non de la catégorieId, il suffit d'ajouter au classeur modèle, également d'accord, il serait logique d'utiliser la liaison de modèle pour raccourcir la signature de la méthode et la garder propre.
Pour l'entité modèle de chaque catégorie, créez une vue de modèle qui filtre les propriétés conformes au marché actuel,
Créer éventuellement un dictionnaire de propriétés non filtrées sur la mouche
ou signaler la vue d'une autre manière que les propriétés à ignorer / ne pas ignorer.
- Si le filtrage par propriété est trop, vous pouvez utiliser une vue de modèle distincte par marché (à l'aide d'un dictionnaire). P>
Vous pouvez également utiliser des vues séparées, cependant qui vous laisserait des charges de vues - une vue dynamique qui charge le modèle de visualisation correct en fonction de la vue (trouve la vue Modèle via le contrôleur) et prend le modèle de vue Les filtres en considération seraient plus élégants. P>
Configurez une table dans votre base de données qui ressemble à quelque chose comme ceci: puis stocke chaque combinaison d'attributs dont vous avez besoin dans cette table ( évidemment, certains refactoring peuvent être effectués. , comme présentant une table "attributs" qui stocke si un attribut est requis ou non pour l'insert rapide et permettrait aux combos de catégorie / marché de partager des attributs em>). p> Alors à votre vue, lisez La catégorie de l'utilisateur et la combo du marché et construisent dynamiquement le formulaire: p> dans votre page.Load pour le formulaire, instaniez les pièces de formulaire dont vous avez besoin, donnez-leur des identifiants significatifs, puis dans votre gestionnaire de publication, lisez toutes les données. à partir de l'objet request.form. p> Un court exemple: p>
Tous les produits tombent-ils dans une piste de catégorie toutes les attributs de cette catégorie? On peut la même chose pour les attributs de chaque marché cible?
Ou, est la relation entre les catégories et les marchés cibles hiérarchial? Catégorie -> Marché ciblé -> Set d'attributs
L'ensemble des attributs de produit est-il égal à l'ensemble des attributs de catégorie ainsi que l'ensemble des attributs de marché cible, où le marché cible dépend de la catégorie?
Voir mon édition dans la question ... Pour résumer cependant, il est hiérarchique, pas la somme des attributs de catégorie et des attributs du marché.