ASP.Net MVC métodos de ação ambigiosos - por que o caminho escolhido

5

Existe alguém que poderia lançar uma luz sobre por que métodos ambíguos não são permitidos no asp.net MVC?
Eu atualizei minha pergunta apenas para esclarecê-lo (usando exemplo Carson63000 de sua resposta), a questão em si permanece a mesma .

Então, digamos que temos a seguinte ação

/article/list/sport

quais chamadas

public ActionResult List(string category) { }

e também deseja ter a seguinte ação:

/article/list/sport/20110904

que gostaríamos de chamar de método de acompanhamento

public ActionResult List(string category, DateTime date) { }

Atualmente, o framework lança um AmbiguousMatchException , pois encontrou dois métodos chamados List. Essa é a única razão para lançar a exceção, que foi encontrado mais de um método que corresponde ao nome das ações.

Após a estrutura ter descoberto o método a ser usado e decidido que não é ambíguo, ele tentará mapear os dados fornecidos da solicitação para os parâmetros do método. Por que não fazer isso ao contrário? Primeiro, obtenha todos os métodos aplicáveis e, em seguida, tente encontrar o melhor ajuste mapeando os parâmetros.

Se métodos ambíguos forem permitidos, acho que ainda é possível fazer o seguinte.
Como /article/list/sport usa a rota /{controller}/{action}/{category} e que /article/list/sport/20110903 usa a rota /{controller}/{action}/{category}/{date}
, ainda seria possível mapear dados para url /article/list/sport?date=20110903 , pois ela corresponderá à rota apenas para categoria, mas ainda pode mapear os dados para o método public ActionResult List(string category, DateTime date) { } .

No momento, não vejo a razão para não permitir métodos ambíguos do ponto de vista do design. A única coisa em que consigo pensar é que isso atrasa demais o framework e, portanto, a solução atual é a mais lógica. Ou estou perdendo outro ponto aqui?

    
por Major Byte 31.08.2011 / 23:35
fonte

2 respostas

4

Se eu entendi sua pergunta corretamente, eu diria que é porque você geralmente não tem controle explícito sobre os parâmetros passados para uma ação.

Lembre-se de que a vinculação do modelo, por padrão, os levará de vários lugares diferentes, incluindo aqueles que estão fora do seu controle, como querystring.

Parece que você está pensando que deveria ter algo assim:

/article/list/sport

Que chama ArticleController.List(string category);

E também:

/article/list/sport/20110901

Que chama ArticleController.List(string category, DateTime date);

Mas o que acontece quando alguém digita o URL /article/list/sport?date=20110902 ?

Isso soa como uma receita para um comportamento imprevisível e, em troca, que benefício real você teria com esse tipo de sobrecarga de ação?

    
por 01.09.2011 / 01:54
fonte
-1

Quanto a obter uma lista de métodos aplicáveis para resolver uma ação, não vejo qualquer problema com isso, é bastante factível, como se viu. Resolver os parâmetros para cada método também é gerenciável, o único problema que parece existir é determinar o melhor ajuste.

Mas ainda assim deve ser possível escolher um método sobre outro de alguma forma e se houver algum tipo de empate, lance o AmbiguousMethodException.

    
por 13.09.2011 / 21:50
fonte