Gestion des URL complexes dans ASP MVC

Question

J'ai, je pense, une URL complexe à traiter dans ASP MVC 1.0: Toutes mes actions dans la plupart des contrôleurs nécessitent deux paramètres à tout moment: Account et Project. Ceci est au-dessus des exigences de chaque action. Cela signifie qu'une URL typique est comme ceci:

http://abcd.com/myaccount/projects/project_id/sites/edit/12

Dans cet exemple: mon compte est le nom du compte. Les projets peuvent être un contrôleur, d'autres options sont comme les emplacements , les employés . id_projet est l'identifiant d'un projet dans mon compte , les sites peuvent être un contrôleur, les autres options sont comme personnel ou paiements . modifier est une action et 12 l'identifiant du site modifié. (espérons que cela soit suffisamment clair)

Une option consiste maintenant à créer une route et à transmettre le project_id et le compte à toutes les actions des contrôleurs en ajoutant deux paramètres supplémentaires à toutes les actions. Ce n'est pas vraiment souhaitable et je ne suis pas sûr que les deux contrôleurs (projets et sites) vont fonctionner ici.

Ma situation idéale consiste à utiliser un type de contexte qui accompagne l'appel de l'action du contrôleur et à y stocker project_id et mon compte. Le reste des paramètres peut alors être traité de manière normale comme:

// sitescontroller
public ActionResult Edit(string id)
{
string account = somecontext["account"];
string project_id = somecontext["project"];
// do stuff
}

Avez-vous des idées sur comment / où cela peut se produire? Comment cela va-t-il fonctionner avec ActionLink (c.-à-d. Générer des liens corrects en fonction de ce contexte)?

Merci!

Answer 1

Vous devez d'abord ajouter les jetons à vos itinéraires, par exemple {société} / projets / {projet} {contrôleur} / {action} / {id} . Ensuite, si vous écriviez votre propre IControllerFactory, il serait très facile de transférer les valeurs de RouteData dans le contrôleur via le constructeur ou comme vous le souhaitez. Le moyen le plus simple de commencer serait probablement de sous-classer DefaultControllerFactory et de remplacer la méthode CreateController.

Answer 2

Cela n’a pas vraiment de sens pour moi. Pourquoi voudriez-vous un itinéraire semblable à celui-ci:

{controller}/{id}/{controller}/{id}

?