¿Puede sobrecargar los métodos del controlador en ASP.NET ¿MVC?

Sí. He sido capaz de hacer esto mediante el establecimiento de la HttpGet/HttpPost (o atributo AcceptVerbs equivalente) para cada método controlador a algo distinto, es decir, HttpGet o HttpPost, pero no ambos. De esa manera, puede decir en función del tipo de solicitud qué método usar.

[HttpGet]
public ActionResult Show()
{
   ...
}

[HttpPost]
public ActionResult Show( string userName )
{
   ...
}

Una sugerencia que tengo es que, para un caso como este, sería tener una implementación privada en la que ambos métodos de Acción pública se basen para evitar la duplicación de código.

Aquí hay algo más que podrías hacer... desea un método que sea capaz de tener un parámetro y no.

¿Por qué no probar esto?..

public ActionResult Show( string username = null )
{
   ...
}

Esto ha funcionado para mí... y en este método, realmente puede probar para ver si tiene el parámetro entrante.

No,No y No. Vaya y pruebe el código del controlador a continuación donde tenemos el" LoadCustomer " sobrecargado.

public class CustomerController : Controller
    {
        //
        // GET: /Customer/

        public ActionResult LoadCustomer()
        {
            return Content("LoadCustomer");
        }
        public ActionResult LoadCustomer(string str)
        {
            return Content("LoadCustomer with a string");
        }
    }

Si intenta invocar la acción "LoadCustomer" obtendrá un error como se muestra en la siguiente figura.

El polimorfismo es una parte de la programación en C# mientras que HTTP es un protocolo. HTTP no entiende el polimorfismo. HTTP funciona en el concepto o URL y la URL solo puede tener un nombre único. Por lo tanto, HTTP no implementa polimorfismo.

Con el fin de fijar la igual necesitamos usar el atributo "ActionName".

public class CustomerController : Controller
    {
        //
        // GET: /Customer/

        public ActionResult LoadCustomer()
        {
            return Content("LoadCustomer");
        }

        [ActionName("LoadCustomerbyName")]
        public ActionResult LoadCustomer(string str)
        {
            return Content("LoadCustomer with a string");
        }
    }

Así que ahora si haces una llamada a URL "Customer/LoadCustomer" se invocará la acción "LoadCustomer" y con la estructura URL "Customer/LoadCustomerByName" se invocará la acción "LoadCustomer(string str)".

La respuesta anterior la he tomado de este artículo de codeproject > > MVC Action overloading

Para superar este problema, puede escribir un ActionMethodSelectorAttribute que examine el MethodInfo para cada acción y lo compare con los valores del formulario publicados y luego rechace cualquier método para el que los valores del formulario no coincidan (excluyendo el nombre del botón, por supuesto).

Aquí hay un ejemplo: - http://blog.abodit.com/2010/02/asp-net-mvc-ambiguous-match /

PERO, esto no es una buena idea.

Por lo que sé, solo se puede tener el mismo método cuando se usan diferentes métodos http.

Es decir,

[AcceptVerbs("GET")]
public ActionResult MyAction()
{

}

[AcceptVerbs("POST")]
public ActionResult MyAction(FormResult fm)
{

}

He logrado esto con la ayuda de Enrutamiento de atributos en MVC5. Es cierto que soy nuevo en MVC viniendo de una década de desarrollo web utilizando formularios web, pero lo siguiente ha funcionado para mí. A diferencia de la respuesta aceptada, esto permite que todas las acciones sobrecargadas sean renderizadas por el mismo archivo de vista.

Primero habilite el Enrutamiento de atributos en App_Start/RouteConfig.cs.

public class RouteConfig
{
    public static void RegisterRoutes(RouteCollection routes)
    {
        routes.IgnoreRoute("{resource}.axd/{*pathInfo}");

        routes.MapMvcAttributeRoutes();

        routes.MapRoute(
            name: "Default",
            url: "{controller}/{action}/{id}",
            defaults: new { controller = "Home", action = "Index", id = UrlParameter.Optional }
        );            
    }
}

Opcionalmente decora tu clase controller con un prefijo de ruta predeterminado.

[RoutePrefix("Returns")]
public class ReturnsController : BaseController
{
    //.......

Luego decorar sus acciones de controlador que se sobrecargan entre sí con una ruta común y parámetros para adaptarse. Con los parámetros de tipo restringido, puede usar el mismo formato URI con ID de diferentes tipos.

[HttpGet]
// Returns
public ActionResult Index()
{
    //.....
}

[HttpGet]
[Route("View")]
// Returns/View
public ActionResult View()
{
    // I wouldn't really do this but it proves the concept.
    int id = 7026;
    return View(id);
}

[HttpGet]
[Route("View/{id:int}")]
// Returns/View/7003
public ActionResult View(int id)
{
    //.....
}

[HttpGet]
[Route("View/{id:Guid}")]
// Returns/View/99300046-0ba4-47db-81bf-ba6e3ac3cf01
public ActionResult View(Guid id)
{
    //.....
}

Espero que esto ayude y no esté guiando a alguien por el camino equivocado. :-)

Podrías usar un solo ActionResult para tratar con Post y Get:

public ActionResult Example() {
   if (Request.HttpMethod.ToUpperInvariant() == "GET") {
    // GET
   }
   else if (Request.HttpMethod.ToUpperInvariant() == "POST") {
     // Post  
   }
}

Útil si sus métodos Get y Post tienen firmas coincidentes.

Acabo de encontrar esta pregunta y, a pesar de que es bastante antigua ahora, sigue siendo muy relevante. Irónicamente, el único comentario correcto en este hilo fue publicado por un principiante confeso en MVC cuando escribió el post. Incluso el ASP.NET los documentos no son del todo correctos. Tengo un gran proyecto y con éxito sobrecargar los métodos de acción.

Si uno entiende el enrutamiento, más allá del simple patrón de ruta predeterminado {controller} / {action} / {id}, puede ser obvio que las acciones del controlador pueden ser mapeado usando cualquier patrón único. Alguien aquí habló del polimorfismo y dijo: "HTTP no entiende el polimorfismo", pero el enrutamiento no tiene nada que ver con HTTP. Es, en pocas palabras, un mecanismo para la coincidencia de patrones de encordado.

La mejor manera de hacer que esto funcione es usar los atributos de enrutamiento, por ejemplo:

[RoutePrefix("cars/{country:length(3)}")]
public class CarHireController
{
    [Route("{location}/{page:int=1}", Name = "CarHireLocation")]
    public ActionResult Index(string country, string location, int page)
    {
        return Index(country, location, null, page);
    }

    [Route("{location}/{subLocation}/{page:int=1}", Name = "CarHireSubLocation")]
    public ActionResult Index(string country, string location, string subLocation, int page)
    {
        //The main work goes here
    }
}

Estas acciones se encargarán de url como /cars/usa/new-york y /cars/usa/texas/dallas, que se asignarán a la primera y segunda acciones de índice respectivamente.

Examinando este ejemplo controlador es evidente que va más allá del patrón de ruta predeterminado mencionado anteriormente. El valor predeterminado funciona bien si la estructura de la url coincide exactamente con las convenciones de nomenclatura del código, pero este no siempre es el caso. El código debe ser descriptivo del dominio, pero las url a menudo necesitan ir más allá porque su contenido debe basarse en otros criterios, como los requisitos de SEO.

El beneficio del patrón de enrutamiento predeterminado es que crea automáticamente rutas únicas. Esto se hace cumplir por el compilador ya que las url coincidirán con tipos de controladores y miembros únicos. Rodar sus propios patrones de ruta requerirá un pensamiento cuidadoso para garantizar la singularidad y que funcionen.

Nota importante El único inconveniente es que el uso de enrutamiento para generar urls para acciones sobrecargadas no funciona cuando se basa en un nombre de acción, por ejemplo, cuando se utiliza UrlHelper.Acto. Pero funciona si se usan rutas con nombre, por ejemplo, UrlHelper.RouteUrl. Y el uso de rutas con nombre es, según fuentes muy respetadas, el camino a seguir de todos modos ( http://haacked.com/archive/2010/11/21/named-routes-to-the-rescue.aspx/).

¡Buena suerte!

Necesitaba una sobrecarga para:

public ActionResult Index(string i);
public ActionResult Index(int groupId, int itemId);

Hubo pocos argumentos suficientes donde terminé haciendo esto:

public ActionResult Index(string i, int? groupId, int? itemId)
{
    if (!string.IsNullOrWhitespace(i))
    {
        // parse i for the id
    }
    else if (groupId.HasValue && itemId.HasValue)
    {
        // use groupId and itemId for the id
    }
}

No es una solución perfecta, especialmente si tienes muchos argumentos, pero funciona bien para mí.

Puede usar [ActionName ("NewActionName")] para usar el mismo método con un nombre diferente:

public class HomeController : Controller
{
    public ActionResult GetEmpName()
    {
        return Content("This is the test Message");
    }

    [ActionName("GetEmpWithCode")]
    public ActionResult GetEmpName(string EmpCode)
    {
        return Content("This is the test Messagewith Overloaded");
    }
}

También me he enfrentado al mismo problema en mi solicitud. Sin modificar ninguna información del método, he proporcionado [ActionName ("SomeMeaningfulName")] en la cabeza de la acción. problema resuelto

[ActionName("_EmployeeDetailsByModel")]
        public PartialViewResult _EmployeeDetails(Employee model)
        {
            // Some Operation                
                return PartialView(model);
            }
        }

[ActionName("_EmployeeDetailsByModelWithPagination")]
        public PartialViewResult _EmployeeDetails(Employee model,int Page,int PageSize)
        {

                // Some Operation
                return PartialView(model);

        }

Crear el método base como virtual

public virtual ActionResult Index()

Crea el método sobrescrito como override

public override ActionResult Index()

Editar: Esto obviamente se aplica solo si el método override está en una clase derivada que parece no haber sido la intención del OP.

Me gusta esta respuesta publicada en otro hilo

Esto se usa principalmente si hereda de otro controlador y desea anular una acction del controlador base

ASP.NET MVC-Sobreescribir una acción con diferentes parámetros

Solo se permite una firma pública para cada método del controlador. Si intenta sobrecargarlo, se compilará, pero obtendrá el error de tiempo de ejecución que ha experimentado.

Si no está dispuesto a usar verbos diferentes (como los atributos [HttpGet] y [HttpPost]) para diferenciar métodos sobrecargados (que funcionarán), o cambiar el enrutamiento, entonces lo que queda es que puede proporcionar otro método con un nombre diferente, o puede enviar dentro del método existente. Aca cómo lo hice:

Una vez llegué a una situación en la que tuve que mantener la compatibilidad hacia atrás. El método original esperaba dos parámetros, pero el nuevo solo tenía uno. Sobrecargar la forma en que esperaba no funcionó porque MVC ya no encontró el punto de entrada.

Para resolver eso, hice lo siguiente:

1. Se cambiaron los 2 métodos de acción sobrecargados de público a privado

2. Creó un nuevo método público que contenía "solo" 2 parámetros de cadena. Que uno actuó como un despachador, es decir:

   public ActionResult DoSomething(string param1, string param2)
   {
       if (string.IsNullOrEmpty(param2))
       {
           return DoSomething(ProductName: param1);
       }
       else
       {
           int oldId = int.Parse(param1);
           return DoSomething(OldParam: param1, OldId: oldId);
       }
   }
   
   
   private ActionResult DoSomething(string OldParam, int OldId)
   {
       // some code here
       return Json(result);
   }
   
   
   private ActionResult DoSomething(string ProductName)
   {
       // some code here
       return Json(result);
   }
   

Por supuesto, esto es un truco y debe ser refactorizado más tarde. Pero por el momento, funcionó para mí.

También puedes crear un despachador como:

public ActionResult DoSomething(string action, string param1, string param2)
{
    switch (action)
    {
        case "update":
            return UpdateAction(param1, param2);
        case "remove":
            return DeleteAction(param1);
    }
}

Puede ver que UpdateAction necesita 2 parámetros, mientras que DeleteAction solo necesita uno.

Si esto es un intento de usar una acción GET para varias vistas que PUBLICAN varias acciones con diferentes modelos, entonces intente agregar una acción GET para cada acción POST que redirija a la primera GET para prevenir 404 en refresh.

Posibilidad remota pero escenario común.