ASP.Net MVC metodi di azione ambigui - perché il percorso scelto

Question

ASP.Net MVC metodi di azione ambigui - perché il percorso scelto

#1 da (4 voti)
#2 da (-1 voti)

5

C'è qualcuno che potrebbe far luce sul perché i metodi ambigui non sono consentiti in ASP.Net MVC?
Ho aggiornato la mia domanda solo per chiarirla (usando l'esempio di Carson63000 dalla sua risposta), la domanda stessa rimane la stessa .

Quindi, diciamo che abbiamo la seguente azione

/article/list/sport

che chiama

public ActionResult List(string category) { }

e vuoi essere in grado di avere anche la seguente azione:

/article/list/sport/20110904

che vorremmo chiamare il metodo di accompagnamento

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

Attualmente il framework lancia un AmbiguousMatchException poiché ha trovato due metodi chiamati List. Questa è l'unica ragione per lanciare l'eccezione, che è stato trovato più di un metodo che corrisponde al nome dell'azione.

Dopo che il framework ha capito quale metodo utilizzare e ha deciso che non è ambiguo, tenterà quindi di mappare i dati forniti dalla richiesta ai parametri del metodo. Perché non farlo al contrario? Per prima cosa ottieni tutti i metodi applicabili e poi prova a trovare la soluzione migliore mappando i parametri.

Se sono permessi metodi ambigui, penso che sia ancora possibile fare quanto segue.
Dato che /article/list/sport usa la rotta /{controller}/{action}/{category} e che /article/list/sport/20110903 usa la rotta /{controller}/{action}/{category}/{date}
sarebbe quindi ancora possibile mappare i dati per url /article/list/sport?date=20110903 poiché corrisponderà al percorso per la sola categoria, ma può ancora mappare i dati per il metodo public ActionResult List(string category, DateTime date) { } .

Al momento non riesco a vedere la ragione per non consentire metodi ambigui dal punto di vista del design. L'unica cosa che posso pensare a me stesso è che rallenterà troppo la struttura, e quindi la soluzione attuale è la più logica. O mi manca un altro punto qui?

c# asp.net-mvc asp.net-mvc-3

posta Major Byte 31.08.2011 - 23:35

fonte

2 risposte

Leggi altre domande sui tag c# asp.net-mvc asp.net-mvc-3

Dettaglio dei criteri di accettazione nella user story Mantenimento di un elenco di nodi con requisiti impegnativi

score 4 · Answer 1

Se comprendo correttamente la tua domanda, direi che è perché generalmente non hai il controllo esplicito sui parametri passati a un'azione.

Ricorda che il binding del modello, per impostazione predefinita, prenderà da un certo numero di luoghi diversi, inclusi quelli che sono fuori dal tuo controllo, come la querystring.

Sembra che tu stia pensando che dovresti essere in grado di avere qualcosa del genere:

/article/list/sport

Che chiama ArticleController.List(string category);

E anche:

/article/list/sport/20110901

Che chiama ArticleController.List(string category, DateTime date);

Ma cosa succede quando qualcuno digita l'URL /article/list/sport?date=20110902 ?

Sembra solo una ricetta per un comportamento imprevedibile e, in cambio, quale vantaggio otterresti da questo tipo di sovraccarico di azioni?

score -1 · Answer 2

Come ottenere un elenco di metodi applicabili per risolvere un'azione, non vedo alcun problema con questo, è abbastanza facilmente fattibile, come si è scoperto. Anche la risoluzione dei parametri per ciascun metodo è gestibile, l'unico problema che sembra esistere è determinare la soluzione migliore.

Tuttavia, dovrebbe essere possibile scegliere un metodo piuttosto che un altro e, se ci fosse una sorta di legame, lanciare AmbiguousMethodException.