ASP MVC Parametri di azione tutte le stringhe vs tipo esplicito

In realtà stai facendo due diverse domande qui.

1. I parametri MVC dovrebbero essere tutti stringhe?

   Certo che non dovrebbero. Il fatto che tu voglia cambiare il tipo più tardi è un argomento assurdo; da qualche parte, in qualche modo, alcuni componenti dipenderanno dal fatto che quell'ID sia un tipo specifico, e in futuro non sarà più facile o meno rischioso cambiare un numero di casts e type checks di quanto non cambierà il tipo di un parametro.

   Se i progettisti di ASP.NET MVC non desideravano che si utilizzassero parametri strongmente tipizzati (o l'equivalente più sofisticato, l'associazione del modello con proprietà strongmente tipizzate), non avrebbero scritto una tonnellata di codice per supportare esattamente quello scenario. La strong digitazione è uno dei motivi principali per utilizzare un framework come MVC, invece di framework legacy in cui bisognava avvitare Request.QueryString e così via.

   Se ti perdi i bei vecchi tempi di Request.Form e Request.QueryString e non pensi di aver mai bisogno di sovraccaricare nessuno dei tuoi metodi di azione, allora con tutti i mezzi converti tutti i tuoi parametri in stringhe di nostalgia. Se rimani ancora un po 'di sanità mentale, sfrutterai l'ampia convalida incorporata in MVC per tua comodità e utilizzerai i tipi corretti.

2. Gli ID dovrebbero essere stringhe?

   Questa è una domanda molto più difficile a cui rispondere perché molto spesso dipende dall'ID .

   Molto spesso potresti avere diversi sviluppatori e / o diversi team che lavorano sullo stesso prodotto o funzione. Spesso ci sarà il codice del modello di dominio e / o le API scritte prima che qualcuno abbia la minima idea di come o dove verrà immagazzinato. Altre volte lavorerai in stile DDD / BDD e vorresti esprimere il fatto che non importa di che tipo si tratti perché non è associata alcuna convalida.

   Come vedi, le web API si prestano molto bene al modello string-as-ID, perché non importa quale sia il tipo sottostante, la gestione degli errori è banalmente semplice: prova a convertire nel tipo previsto, e se la conversione fallisce, quindi restituisce un 404. Un ID non valido è funzionalmente uguale a una risorsa mancante.

   Quanto sopra non funziona se si consente al client di specificare i propri ID per le nuove risorse, ma poi di nuovo, se si ha intenzione di consentire al client di specificare i propri ID, si veramente dovrebbe rende l'ID una stringa invece di imporre restrizioni arbitrarie e probabilmente prive di documenti sul client. Gli ID non stringa sono in genere non stringhe in modo specifico perché devono essere generati automaticamente, ad es. una sequenza intera, un GUID, un ID oggetto BSON, ecc. Se l'ID non viene generato automaticamente, una stringa è in genere la scelta migliore per il modello di dati sottostante perché consente la visualizzazione degli ID più leggibili.

   I preferisco utilizzare gli ID stringa nella mia API e / o nei modelli di visualizzazione perché mi risparmia dovermi preoccupare di ciò che i membri del database stanno facendo e / o potenzialmente di dover affrontare una modifica del tipo. Ma questa è solo una preferenza personale della mia esperienza personale e certamente non una regola ferrea su MVC; ci sono alcuni framework / prodotti che hanno problemi con gli ID delle stringhe (RavenDB, ti sto guardando) quindi non è una decisione che dovresti prendere alla leggera, a meno che tu non possa capire e prevedere le conseguenze.

Quindi c'è un valore di alcuni nell'argomento sul rendere l'ID una stringa - ma non nel fare tutti delle stringhe dei parametri senza un vero motivo. È strano e farei un dump fumante su di esso se mai lo vedessi in una recensione del codice.

Should parameters to Action methods be all strings if that is going to make it more flexible in the future, or should they be specific to their type so that we can leverage MVC binding and error handling?

In breve: No , ogni parametro dovrebbe rappresentare il tipo che il tuo metodo si aspetta. Altrimenti, dovresti controllare ciascun parametro e eseguire il cast su tipi specifici all'interno del metodo.

Ad esempio, prendi il tipo DateTime . Se lo si passa come stringa, è necessario eseguire il cast per ottenere il valore DateTime effettivo, mentre il binding del modello MVC lo fornisce immediatamente.

Attualmente, il nostro team sta lavorando su una grande applicazione asp.net di mvc e seguiamo diverse buone pratiche nel progetto. Uno di questi è di consentire nullable types per i parametri che possono avere valori nulli, quando richiesto o pubblicato. Questo approccio aiuta molto con i parametri di ricerca opzionali che l'utente finale può / non può fornire.

Suggerisco di scrivere solo il codice per risolvere il tuo problema attuale e il tuo attuale problema solo .

Se approfittare dell'associazione MVC, della convalida sul lato client, ecc. semplifica la risoluzione del problema corrente, quindi scegli quello che risolve il problema corrente che stai cercando di risolvere.

E nel caso in cui non fossi chiaro prima, concentrati solo sul tuo attuale problema.