MVC 3 post de formulaire et la persistance du modèle de données

Je pense que je suis pas certains principes fondamentaux sur la façon dont MVC formes de travail. J'ai un formulaire de recherche sur ma page d'accueil qui a cinq ou six les différents champs d'un utilisateur peut effectuer une recherche. J'ai donc cette annonce à mes résultats de l'action de l'amende juste. Le Résultat de l'action ressemble à ceci:

[HttpPost]
public ActionResult Results(SearchModel model)
{
    ResultsModel results = new ResultsModel();
    results.ResultList = SearchManager.Search(model).ToList();

    return View("Results", results);
}

J'ai simplifié la méthode ci-dessus pour ce post, mais l'idée est la même. Donc, tout cela fonctionne très bien. Ma page de résultats s'affiche avec la liste de résultats et de mon utilisateur est à l'URL suivante:

http://www.site.com/results

Alors...maintenant je veux faire quelque chose de relativement commun. J'ai deux listes déroulantes sur la page de résultats. "Trier par" et "le nombre de résultats par page". Comment puis-je le faire et envoyer l'ensemble des données du modèle vers le contrôleur afin que je puisse requête avec les nouveaux paramètres? En réalité, la SearchModel classe a environ 60 différents domaines. Potentiellement toutes les données pouvaient être contenues dans le modèle. Comment vous obstinez-vous que pour une page "publier"?

Cette même question m'a un peu perplexe sur la façon de faire de la pagination ainsi. Mes liens de pagination serait aller à l'URL:

http://www.site.com/results/2

Mais qui suppose que nous sommes de répondre à une requête GET (je ne veux pas 60 champs de données dans la chaîne de requête) et que le modèle de données est passé entre les requêtes GET, qui je sais n'est pas le cas.

Comme je l'ai dit, je pense que je suis pas certains principes fondamentaux sur le travail avec MVC 3, les modèles et la forme des messages.

Quelqu'un peut-il aider à me diriger dans la bonne direction ici? Je serai heureux de modifier/mettre à jour ce post au besoin de clarifier les choses.

MODIFIER: je voulais aussi faire remarquer, j'aimerais éviter de stocker le modèle de vue dans une variable de Session. Ce site finira par être d'équilibrage de charge dans une batterie de serveurs web et je suis vraiment essayer d'éviter d'utiliser de la Session, si possible. Cependant, si c'est la seule alternative, je vais configurer un autre fournisseur d'état de session, mais je préfère ne pas le faire.

  • Hm j'aimerais entendre une opinion d'expert à ce sujet que bien, mais tomé-moi, vous avez l'option de emply Session, directement ou indirectement, par TempData. L'autre option est d'avoir des tonnes de champs cachés sur la page de résultat.
  • désolé, la partie cachée des champs est un non-sens. à mon humble avis la façon la plus propre est d'utiliser tempdata.
  • il se sent encore comme 2001 🙁
InformationsquelleAutor Scott | 2011-05-01
  1. 17

    Vous pouvez ajouter votre SearchModel paramètres de l'itinéraire de valeurs pour votre formulaire. Plusieurs versions de BeginForm permettra de passer un objet/RouteValuesDictionary. 

    @Html.BeginForm("Action", "Controller", new { SearchModel = Model }, FormMethod.Post)

    Cela devrait passer-par le biais de votre SearchModel valeurs de sorte que vous pouvez ré-utiliser pour obtenir la page suivante. Vous avez besoin d'un contrôleur d'action défini qui va accepter de tout courant-page formulaire de valeurs ainsi que la SearchModel.

    Je n'ai pas fait cette avec la forme de postes, mais de ce que j'ai fait et de ce que les docs disent, c'est là que je commencerais. Bien sûr, cela signifie aussi que chacun de vos numéro de la page "liens" sur la page aura besoin de faire des posts. C'est vraiment gênant pour les utilisateurs, s'ils veulent être en mesure d'utiliser le bouton précédent du navigateur.

    Dans ce contexte, vous pouvez essayer de définir un itinéraire qui permet le numéro de page doit apparaître comme une partie de l'URL -- "Action/Contrôleur/{page}". Cependant, je ne suis pas sûr de la façon qui fonctionne étant donné que la forme est en train de faire un post.

    Réponse au Commentaire:

    Oui, vous pouvez utiliser Route de Valeurs à ajouter les SearchModel pour chaque lien de la page, mais comme je l'ai dit dans le commentaire ci-dessus, puisque les liens ne "la," permettra de voir vos utilisateurs la SearchModel sérialisé en tant qu'une partie du lien.

    De toute façon, à l'aide de l'Itinéraire Valeurs est votre réponse à la de retrouver l'original de votre SearchModel sans l'aide de champs cachés, la Session, ou TempData.

    • Je vais jouet autour de avec si je ne peux pas trouver une autre solution, mais j'aimerais éviter de former des postes trop, lol. Je sens que les utilisateurs s'attendent à être en mesure à la page dans les résultats sans forme postes (afin qu'ils puissent actualiser ou utiliser le bouton de retour) et également être en mesure à la page sans se soucier de leur session d'expirer. Peut-être que c'est juste une lacune de la MVC. Je suis penchée vers l'aide à OBTENIR à ce point et de laisser l'URL d'obtenir un peu désordonné.
    InformationsquelleAutor BJ Safdie
  2. 8

    Votre SearchModel les besoins de la classe pour contenir vos critères de recherche et vos résultats. Quelque chose comme ci-dessous. Si vous utilisez un PagedList pour vos résultats puis il contiendra la page en cours, le nombre de pages, nombre total d'éléments, etc. Vous pouvez limiter la quantité d'informations dans votre page par écrit seulement les critères de recherche qui contiennent des valeurs.

    public class SearchModel
{
    public string Product { get; set; }
    public string Sku { get; set; }
    public string Size { get; set; }
    public string Manufacturer { get; set; }
    //etc...

    public PagedList ResultsList { get; set; }
}


[HttpPost]
public ActionResult Results(SearchModel model)
{
    model.ResultList = SearchManager.Search(model).ToList();
    return View(model);
}
    • C'est une approche intéressante. Je vais essayer ça demain (ou peut-être la prochaine journée) et après revenir ici par la suite.
    InformationsquelleAutor 37Stars
  3. 2

    L'une des options que je suis venue ici est de mettre en œuvre un système de mise en cache distribuée qui prend en charge agissant comme une séance personnalisée fournisseur (c'est à dire Memcached ou Windows Server AppFabric), ce qui me permet d'utiliser TempData (et Session) dans une charge équilibrée de l'environnement comme suit:

    [HttpPost]
public ActionResult Results(SearchModel model)
{
    ResultsModel results = new ResultsModel();
    results.ResultList = SearchManager.Search(model).ToList();

    TempData["SearchModel"] = model;

    return View("Results", results);
}

    [HttpGet]
    public ActionResult Results(int? page)
    {
        SearchModel model = (SearchModel)TempData["SearchModel"];

        ResultsModel results = new ResultsModel();
        results.ResultList = SearchManager.Search(model).ToList();

        TempData["SearchModel"] = model;

        return View("Results", results);
    }

    Toute réflexion sur cette approche? Semble comme beaucoup de aller à travers juste pour obtenir les paramètres de recherche passé entre les demandes. Ou peut-être que j'étais juste gâté avec tout cela se passe en coulisses avec les Formulaires web. 🙂

    • Grrr...petit problème avec cela. TempData évidemment utilise toujours de la Session. Je ne veux pas que l'utilisateur de ne pas être en mesure d'aller à la page suivante de résultats, juste parce qu'ils sont repartis pour 20 minutes et de leur session a expiré. Ce genre de chose ne devrait pas besoin de Session. Toutes les idées sur ce point? Ce doit être vraiment simple. Je pense que je suis plus compliquer il.
    • Scott, vous pouvez utiliser TempData juste pour remplir les champs masqués sur la page de résultat. De cette façon, la session ne marche pas question dans davantage de demandes. Btw. TempData sont automatiquement jetés après l'avoir utilisé pour initialiser la vue .
    • Les champs cachés ne fonctionne pas bien ici. Mes liens de pagination sont tout simplement en train de "site.com/results/2" (en page 2). Chaque pagination lien n'est pas la soumission d'un formulaire bouton de sorte que ces champs cachés ne sera jamais envoyé. Cela semble juste comme un simple problème, peut-être que je suis à l'approche de la mauvaise façon. Je serais vraiment intéressé d'entendre comment les autres ont résolu ce, même sans prendre en compte mon approche.
    • Soit les liens sont à faire un post, ou vous avez besoin d'ajouter le SearchModel à leur itinéraire de valeurs, dans ce cas, je suis sûr que vous verrez le sérialisé SearchModel dans la chaîne de requête.
    InformationsquelleAutor Scott
  4. 0

    Ce qui semble être une autre option intéressante pour les Webforms gâté gars 😉 La persistance du modèle de l'état dans ASP.NET MVC à l'aide de Sérialiser HTMLHelper
    Une sorte de l'état d'affichage de l'incarnation. Il fait partie de la MVC Terme . Pas sûr de combien de temps il est en Terme de projet et pourquoi il ne peut pas obtenir dans la principale lib.

    InformationsquelleAutor Boris Bucha