Actions de routage et contrôleur - données en option

Question

J'ai créé un itinéraire dans l'application ASP.net MVC qui ressemble à ceci:

routes.MapRoute(
    "ArticleRoute", 
    "{year}/{month}/{day}/{articleId}/{displayName}", 
    new { controller = "Article", action = "Details" } 
); 

Je veux un itinéraire qui sera comme un article de blog.

Exemple: http://www.foobar.com/2010/01/01/123456789/the-name-of-the-article

Dans mon action Détails contrôleur Je veux faire une redirection permanente si l'année, le mois, la date et le nom d'affichage ne sont pas correctes. Je veux savoir la meilleure façon d'écrire la méthode du contrôleur Details().

Le seul champ réellement requis est l'articleId. Si j'ai l'identifiant de l'article, la base de données aura la date et le nom de l'article. Je veux vraiment savoir à quoi devrait ressembler la méthode du contrôleur. Est-ce que je passe toutes les valeurs à la méthode ou utilise RouteData pour les obtenir?

public ActionResult Details(int articleId, string displayName) 
{ 
    var article = */SNIP*/; 

    int articleYear = RouteData.Values["year"]; 
    // etc. 
    DateTime articleDate = new DateTime(articleYear, articleMonth, articleDay); 

    string realDisplayName = article.Name.ToSeoString(); 

    if(displayName != realDisplayName || article.Date != articleDate) 
     // permanent redirect to the actual article 

    return View(); 
} 

OU

public ActionResult(int year, int month, int day, int articleId, string displayName) 
{ 
    var article = /*SNIP*/; 

    DateTime articleDate = new DateTime(year, month, day); 

    string realDisplayName = article.Name.ToSeoString(); 

    if(displayName != realDisplayName || article.Date != articleDate) 
     // permanent redirect to the actual article 

    return View(); 
} 

Je pense que les deux travaillent sur le plan technique, mais qui est la meilleure façon?

Aussi: s'il y a d'autres failles dans ce que je fais, n'hésitez pas à les signaler.

Answer 1

Je préfère les URLs RESTFul pour interroger les chaînes car elles sont claires, peuvent être facilement lues par les utilisateurs et seo friendly.

Dans votre cas si vous voulez vraiment l'url comme .../2010/01/01/123456789/the-name-of-the-article la deuxième méthode est la meilleure.

Mais je pense qu'il n'y a pas besoin d'utiliser les données/mois si vous utilisez l'id de l'article dans l'URL.

Des applications comme wordpress utilisent le format/year/month/title car si vous ne donnez que le titre de l'article, cela prend plus de temps pour interroger la base de données. Mais avec l'année et le mois, vous pouvez accélérer l'interrogation db puisque vous pouvez affiner les résultats et ensuite faire la recherche de titre sur cet ensemble de résultats.

Je pense que vous devriez utiliser un itinéraire comme .../123456789/le nom de-the-article

Voir l'url de cette question, il est Routing and Controller Actions - Optional Data ici le titre de la question est utilisée uniquement pour la fins de référencement.

Si vous voulez que la conception soit pur reposant l'URL doit être .../articles/le nom de-the-article

Je crée urls comme celui-ci car il y a plusieurs façons d'optimiser la db interrogation (comme le hachage) et j'aime le repos pur.

Answer 2

Dans le cas du premier exemple, quel est le point de passer quelque chose si vous allez utiliser RouteData.Values ​​pour obtenir des valeurs?

De même, l'article var = ... est-il un espace réservé pour l'instant jusqu'à ce que vous branchiez la recherche dans la base de données? Du point de vue du client, cela n'aurait pas d'importance, car l'URL ne serait pas différente. Du côté serveur, le second exemple est plus propre dans le code, car vous n'avez pas la recherche de RouteData.Values.

Answer 3

Les chaînes de requête sont bien meilleures que les URL REST. Les routes datent des premiers jours de HTTP, mais ont été transmises pour des chaînes de requête pour de nombreux sites Web, car les paramètres dépendent de la construction de la route. En outre, les routes ne sont pas bonnes pour chiffrer les paramètres lorsque vous en avez besoin.

Answer 4

Tout laisser passer est meilleur car vos paramètres sont fortement typés et la collection RouteData.Values ​​ne l'est pas. Vous pouvez également convertir les éléments RouteData.Values, mais c'est un code supplémentaire que vous n'avez pas à faire. C'est un autre exemple de ASP.NET MVC qui fait du code pour vous, donc vous avez moins de contrôle si vous voulez faire quelque chose de différent. Les formulaires Web sont plus transparents pour ce que le framework est réellement en train de faire, alors que MVC est fugace.