Je suis curieux de voir si vous pouvez surcharger les méthodes de contrôleur dans ASP.NET MVC. Chaque fois que j'essaye, j'obtiens l'erreur ci-dessous. Les deux méthodes acceptent des arguments différents. Est-ce quelque chose qui ne peut pas être fait?
La demande d'action actuelle «MyMethod» sur le type de contrôleur «MyController» est ambiguë entre les méthodes d'action suivantes:
c#
asp.net-mvc
overloading
Papa Bourgogne
la source
la source
Réponses:
Vous pouvez utiliser l'attribut si vous souhaitez que votre code effectue une surcharge.
Mais, vous devrez utiliser un nom d'action différent pour la même méthode http (comme d'autres l'ont dit). Ce n'est donc que de la sémantique à ce stade. Préférez-vous avoir le nom dans votre code ou votre attribut?
Phil a un article à ce sujet: http://haacked.com/archive/2008/08/29/how-a-method-becomes-an-action.aspx
la source
return View();
. Par exemple:return View("MyOverloadedName");
.Oui. J'ai pu le faire en définissant le
HttpGet
/HttpPost
(ouAcceptVerbs
attribut équivalent ) pour chaque méthode de contrôleur sur quelque chose de distinct, c'est-à-dire,HttpGet
ouHttpPost
, mais pas les deux. De cette façon, il peut dire en fonction du type de demande quelle méthode utiliser.Une suggestion que j'ai est que, pour un cas comme celui-ci, ce serait d'avoir une implémentation privée sur laquelle vos deux méthodes d'action publiques s'appuient pour éviter la duplication de code.
la source
Show()
méthodes ont des signatures différentes. Si et quand vous devez envoyer des informations dans la version Get, vos versions Get et Post se retrouvent alors avec la même signature, et vous auriez besoin de l'ActionName
attribut ou de l'un des autres correctifs mentionnés dans ce post.ActionNameAttribute
. En pratique, j'ai rarement trouvé que c'était le cas.Voici autre chose que vous pourriez faire ... vous voulez une méthode capable d'avoir un paramètre et non.
Pourquoi ne pas essayer ça ...
Cela a fonctionné pour moi ... et dans cette méthode, vous pouvez réellement tester pour voir si vous avez le paramètre entrant.
Mis à jour pour supprimer la syntaxe nullable non valide sur la chaîne et utiliser une valeur de paramètre par défaut.
la source
string
ne peut pas être annulé.)string
ne peut pas êtrenullable
; mais ça peut l'êtrenull
! Quoi qu'il en soit, j'ai posté le commentaire initial sans sincérité.Non, Non et Non. Essayez le code de contrôleur ci-dessous où le "LoadCustomer" est surchargé.
Si vous essayez d'appeler l'action "LoadCustomer", vous obtiendrez une erreur comme indiqué dans la figure ci-dessous.
Le polymorphisme fait partie de la programmation C # tandis que HTTP est un protocole. HTTP ne comprend pas le polymorphisme. HTTP fonctionne sur le concept ou l'URL et l'URL ne peut avoir qu'un nom unique. HTTP n'implémente donc pas le polymorphisme.
Afin de résoudre le même problème, nous devons utiliser l'attribut "ActionName".
Donc maintenant, si vous appelez l'URL "Customer / LoadCustomer", l'action "LoadCustomer" sera invoquée et avec la structure d'URL "Customer / LoadCustomerByName", "LoadCustomer (string str)" sera invoqué.
La réponse ci-dessus que j'ai tirée de cet article de projet de code -> Surcharge de l'action MVC
la source
Pour surmonter ce problème, vous pouvez écrire un
ActionMethodSelectorAttribute
qui examine leMethodInfo
pour chaque action et le compare aux valeurs de formulaire publiées, puis rejette toute méthode pour laquelle les valeurs de formulaire ne correspondent pas (à l'exclusion du nom du bouton, bien sûr).Voici un exemple: - http://blog.abodit.com/2010/02/asp-net-mvc-ambiguous-match/
MAIS, ce n'est pas une bonne idée.
la source
Pour autant que je sache, vous ne pouvez avoir la même méthode que lorsque vous utilisez différentes méthodes http.
c'est à dire
la source
[HttpPost]
attribut au lieu de[AcceptVerbs("POST")]
.J'ai réalisé cela avec l'aide du routage d'attributs dans MVC5. Certes, je suis nouveau sur MVC, issu d'une décennie de développement Web utilisant WebForms, mais ce qui suit a fonctionné pour moi. Contrairement à la réponse acceptée, cela permet à toutes les actions surchargées d'être rendues par le même fichier de vue.
Activez d'abord le routage d'attributs dans App_Start / RouteConfig.cs.
Décorez éventuellement votre classe de contrôleur avec un préfixe de route par défaut.
Décorez ensuite les actions de votre contrôleur qui se surchargent avec une route et des paramètres communs. En utilisant des paramètres à contrainte de type, vous pouvez utiliser le même format URI avec des ID de types différents.
J'espère que cela aide et ne conduit pas quelqu'un sur le mauvais chemin. :-)
la source
Vous pouvez utiliser un seul
ActionResult
pour gérer les deuxPost
etGet
:Utile si vos méthodes
Get
etPost
ont des signatures correspondantes.la source
Je viens de tomber sur cette question et, même si elle est assez ancienne maintenant, elle est toujours très pertinente. Ironiquement, le seul commentaire correct dans ce fil a été posté par un débutant avoué dans MVC lorsqu'il a écrit le message. Même les documents ASP.NET ne sont pas entièrement corrects. J'ai un grand projet et j'ai réussi à surcharger les méthodes d'action.
Si l'on comprend le routage, au-delà du modèle de route par défaut simple {controller} / {action} / {id}, il peut être évident que les actions du contrôleur peuvent être mappées en utilisant n'importe quel modèle unique. Quelqu'un ici a parlé du polymorphisme et a dit: "HTTP ne comprend pas le polymorphisme", mais le routage n'a rien à voir avec HTTP. Il s'agit, en termes simples, d'un mécanisme de correspondance de motifs de chaînes.
La meilleure façon de faire cela est d'utiliser les attributs de routage, par exemple:
Ces actions prendront en charge les URL comme
/cars/usa/new-york
et/cars/usa/texas/dallas
, qui seront mappées respectivement aux première et deuxième actions d'index.En examinant cet exemple de contrôleur, il est évident qu'il va au-delà du modèle de route par défaut mentionné ci-dessus. La valeur par défaut fonctionne bien si votre structure d'URL correspond exactement à vos conventions de dénomination de code, mais ce n'est pas toujours le cas. Le code doit être descriptif du domaine, mais les URL doivent souvent aller plus loin car leur contenu doit être basé sur d'autres critères, tels que les exigences SEO.
L'avantage du modèle de routage par défaut est qu'il crée automatiquement des itinéraires uniques. Ceci est appliqué par le compilateur car les URL correspondent à des types et membres de contrôleur uniques. Rouler vos propres modèles d'itinéraire nécessitera une réflexion approfondie pour garantir l'unicité et le bon fonctionnement.
Remarque importante L'inconvénient est que l'utilisation du routage pour générer des URL pour des actions surchargées ne fonctionne pas lorsqu'elle est basée sur un nom d'action, par exemple, lors de l'utilisation d'UrlHelper.Action. Mais cela fonctionne si l'on utilise des routes nommées, par exemple, UrlHelper.RouteUrl. Et l'utilisation de routes nommées est, selon des sources bien respectées, la voie à suivre ( http://haacked.com/archive/2010/11/21/named-routes-to-the-rescue.aspx/ ).
Bonne chance!
la source
Vous pouvez utiliser [ActionName ("NewActionName")] pour utiliser la même méthode avec un nom différent:
la source
J'avais besoin d'une surcharge pour:
Il y avait assez peu d'arguments où j'ai fini par faire ceci:
Ce n'est pas une solution parfaite, surtout si vous avez beaucoup d'arguments, mais cela fonctionne bien pour moi.
la source
J'ai également rencontré le même problème dans ma candidature. Sans modifier aucune information de méthode, j'ai fourni [ActionName ("SomeMeaningfulName")] sur la tête d'action. problème résolu
la source
Créer la méthode de base comme virtuelle
Créer la méthode remplacée comme remplacement
Edit: Cela ne s'applique évidemment que si la méthode de remplacement est dans une classe dérivée qui ne semble pas avoir été l'intention de l'OP.
la source
J'aime cette réponse publiée dans un autre fil
Ceci est principalement utilisé si vous héritez d'un autre contrôleur et souhaitez remplacer une action du contrôleur de base
ASP.NET MVC - Remplacer une action avec des paramètres différents
la source
Il n'y a qu'une seule signature publique autorisée pour chaque méthode de contrôleur. Si vous essayez de le surcharger, il se compilera, mais vous obtenez l'erreur d'exécution que vous avez rencontrée.
Si vous n'êtes pas prêt à utiliser différents verbes (comme le
[HttpGet]
et[HttpPost]
attributs ) pour différencier les méthodes surchargées (qui fonctionneront) ou modifier le routage, il reste que vous pouvez soit fournir une autre méthode avec un nom différent, soit vous pouvez expédition à l'intérieur de la méthode existante. Voici comment je l'ai fait:Une fois, je me suis retrouvé dans une situation où je devais maintenir une compatibilité ascendante. La méthode d'origine attendait deux paramètres, mais la nouvelle n'en avait qu'un. Surcharger comme je m'y attendais n'a pas fonctionné car MVC n'a plus trouvé le point d'entrée.
Pour résoudre cela, j'ai fait ce qui suit:
Création d'une nouvelle méthode publique qui contenait "juste" 2 paramètres de chaîne. Celui-ci a agi comme répartiteur, c'est-à-dire:
Bien sûr, c'est un hack et devrait être refactorisé plus tard. Mais pour le moment, cela a fonctionné pour moi.
Vous pouvez également créer un répartiteur comme:
Vous pouvez voir que UpdateAction a besoin de 2 paramètres, alors que DeleteAction n'en a besoin que d'un.
la source
Désolé pour le retard. J'étais avec le même problème et j'ai trouvé un lien avec de bonnes réponses, cela pourrait-il aider les nouveaux gars
Tous les crédits pour le site Web BinaryIntellect et les auteurs
Fondamentalement, il existe quatre situations: utiliser différents verbes , utiliser le routage , marquer la surcharge avec l'attribut [NoAction] et changer le nom de l'attribut d'action avec [ActionName]
Cela dépend donc de vos exigences et de votre situation.
Cependant, suivez le lien:
Lien: http://www.binaryintellect.net/articles/8f9d9a8f-7abf-4df6-be8a-9895882ab562.aspx
la source
S'il s'agit d'une tentative d'utiliser une action GET pour plusieurs vues qui POST à plusieurs actions avec différents modèles, essayez alors d'ajouter une action GET pour chaque action POST qui redirige vers le premier GET pour empêcher 404 lors de l'actualisation.
Plan long mais scénario courant.
la source