Comment reconstruire une URL / un itinéraire dans ASP.NET MVC à partir de données enregistrées?

Question

Mon manque de familiarité avec le framework ASP.NET MVC et sa plomberie m'a amené ici, et j'apprécie la patience qu'il faudra à quiconque de lire et d'examiner ma question!

D'accord, voici le scénario: j'ai une application qui comporte de nombreuses pages avec des grilles qui affichent des données basées sur des recherches, des recherches approfondies à partir d'autres données, des rapports basés sur des données spécifiques au contexte (c'est-à-dire qu'ils se trouvent sur une page de détails de Foo , puis cliquez sur un lien qui affiche une table de données liée à Foo), etc.

À partir de n'importe laquelle de ces pages, qui figurent dans l'application, l'utilisateur peut enregistrer le "rapport". ou grille en lui donnant un nom et une description. Cela n'enregistre pas vraiment les données affichées dans la grille, mais enregistre les paramètres définissant l'apparence de la grille, enregistre les paramètres utilisés pour obtenir les données et enregistre les paramètres. qui définissent " où " dans l’application, il s’agit de (action, contrôleur, route) - essentiellement un tas de métadonnées sur le rapport / la grille et sur la façon de la construire.

Tous ces rapports enregistrés sont disponibles dans une seule liste, affichant le nom et la description, sur une page de l'application, chacun étant lié à une URL générique, telle que "/ Reports / Saved / 248". (où 248 est un exemple d'ID du rapport).

Voici la partie sur laquelle j'ai besoin d'aide:

Lorsque j'arrive à l'action via l'URL "/ Reports / Saved / 248" et extraire les métadonnées de la base de données pour ce rapport particulier, comment puis-je rediriger ces données et la demande vers la même action, le même contrôleur et la même route utilisés pour afficher la vue à partir de laquelle le rapport a été enregistré? Pour l’essentiel, je souhaite que l’utilisateur visualise le rapport dans la même vue, avec la même URL que celle à partir de laquelle il a été enregistré. Si possible, je me ferais un plaisir de pouvoir "appeler" cette même action que si je fais un appel de méthode.

UPDATE: Malheureusement, nos pages de rapport (c'est-à-dire les pages sur lesquelles ces grilles apparaissent) n'utilisent PAS les URL RESTful. Par exemple, nous avons ce que nous appelons une page de recherche avancée, qui prend un assez grand nombre de paramètres potentiels (près de 30 ) qui proviennent d'un formulaire contenant des listes de sélection, des zones de texte, etc. Lorsque l'utilisateur soumet cette page, nous effectuons un POST sur une action qui accepte un type complexe que le classeur de modèle construit pour nous - cette même action est ce que je souhaite appeler. lorsque l'utilisateur sélectionne une recherche avancée enregistrée dans la base de données. Cet exemple résume mon problème.

Merci

Answer 1

Je pense que vous voudrez utiliser RedirectToAction avec la signature qui prend un RouteValueDictionary. La méthode vers laquelle vous redirigez devra pouvoir extraire les valeurs de ValueProvider sur le contrôleur. Cela pourrait ressembler à quelque chose comme:

public ActionResult Saved( int id )
{
    var reportParams = db.Reports.SingleOrDefault( r => r.ID == id );
    if (reportParams == null)
       ...handle error...

    var routeValues = ParamsToRouteValueDictionary( reportParams );

    return RedirectToAction( reportParams.Action, reportParams.Controller, routeValues );
}

private RouteValueDictionary ParamsToRouteValueDictionary( object parameters )
{
     var values = new RouteValueDictionary();
     var properties = parameters.GetType().GetProperties()
                                .Where( p => p.Name != "Action" && p.Name != "Controller" );
     foreach (var prop in properties)
     {
         values.Add( prop.Name, prop.GetValue(parameters,null) );
     }

     return values;
}

MODIFIER

L'utilisation d'un modèle de filtre en tant que paramètre de votre méthode peut vous faciliter la tâche. Vous avez juste besoin des versions GET et POST de votre action.

 [ActionName("People")]
 [AcceptVerbs( HttpVerbs.Get )]
 public ActionResult PeopleDisplay( SearchModel filter )
 {
     return People( filter );
 }

 [AcceptVerbs( HttpVerbs.Post)]
 [ValidateAntiForgeryToken]
 public ActionResult People( SearchModel filter )
 {
     ....
 }

Ensuite, vous stockerez dans votre base de données pour le rapport les paramètres de filtre (par nom), l'action ("Personnes") et le contrôleur. Le résultat de la redirection utilisera GET et sera dirigé vers la méthode PeopleDisplay, qui à son tour appelle simplement la méthode People avec le paramètre correct. La publication à partir du formulaire appelle directement la méthode People. L'utilisation de deux méthodes vous permet d'utiliser le mécanisme de prévention CSRF. Vous pouvez éventuellement utiliser un indicateur dans TempData pour vous assurer que l'action GET n'est invoquée via le mécanisme de redirection que si vous souhaitez en restreindre l'accès.

END EDIT

Une autre alternative serait simplement de stocker également la vue utilisée et, au lieu de faire une redirection, de simplement rendre la vue appropriée. L'un des éléments à prendre en compte est que la redirection aboutira à une URL contenant tous les paramètres, tandis que le rendu de la vue laissera l'URL seule et affichera la même vue que celle utilisée lors de la création du rapport. .

Answer 2

Vous pouvez utiliser la méthode RedirectToAction pour émettre une redirection 301 vers une méthode d'action spécifique sur n'importe quel contrôleur, ainsi que des valeurs de route:

ReportMeta meta = _reportDataAccess.Get(id);
return RedirectToAction(meta.Action, meta.Controller, meta.RouteData);

où ces valeurs sont quelque chose comme:

meta.Action = "Bar";
meta.Controller = "Foo";
meta.RouteData = new {
    // possibly settings for the grid
    start = DateTime.Min,
    end = DateTime.Now,
    sort = "Date"
    // you get the idea
};

Bien sûr, le problème immédiat que je peux voir avec ceci est ce qui se passe lorsque vos méthodes de contrôleur / action changent avec le temps, les données du rapport seront invalides. Mais vous y avez probablement déjà pensé.