Parametri dimagranti per un metodo

La migliore funzione è quella senza parametri e senza effetti collaterali :). Sai sempre esattamente cosa sta per fare.

Le funzioni con meno parametri sono più facili da ragionare, quindi sei sulla strada giusta. Il modello di database cambierà mai? Se così fosse, non devi solo cambiare la funzione, ma ogni invocazione della funzione.

Hai idea di passare una parte di dati aggregata contenente tutti i campi è l'idea giusta. Meglio ancora, crea funzioni aggiuntive che inizializzano e impostano i dati per te.

Altrimenti potresti anche creare una singola funzione per ogni campo, ma questo finirebbe con altri accessi al database.

Avere un metodo con 50 parametri sarebbe doloroso da mantenere. Quindi, usa un oggetto. In questo modo la firma del metodo rimane la stessa se è necessario aggiungere nuove proprietà all'oggetto. L'oggetto o il modello può essere passato da un livello all'altro (taglio trasversale) oppure ogni livello può trasformarlo secondo necessità. Modello UI = > Modello di business = > Modello di accesso ai dati.

Inoltre, il modello grande può essere suddiviso in unità più piccole. Sono tutti i 50 campi su una pagina e devono essere aggiornati contemporaneamente? O può essere fatto in piccoli pezzi? Questi sono alcuni elementi da considerare quando si modella la struttura del database in un'azienda o in una interfaccia utente.

Se hai a che fare con i dati dei moduli, come ti sembra, sarei tentato di usare JSON e quindi serializzare / serializzare se necessario.

When I started to look at the database model (which I have no control over) I realized there are 50 columns that have I have to insert data into

La mia prima reazione sarebbe di parlare contro il modello usato; ma questo non aiuta, dato che hai già detto, non hai controllo (o non sei responsabile).

Ora devi occupartene.

Is it ok to have so many input parameters in this method (I am thinking not) and if not what is a good way of dealing with so much data?

Se c'è qualcosa »Okay« dipende da te.

In alcuni casi potrebbe essere "accettabile".

Pro

supponi di avere Good Variable Names ™

Leggi e scrivi codice che si occupa di questo oggetto meno spesso della logica aziendale. Le probabilità sono più alte rispetto alle regole di convalida rispetto alle colonne. Quindi: la "bruttezza" è limitata ad un minimo. Spero: scrivi una volta e non guardare mai più in questo angolo del tuo codice base.

Regola empirica: se ti chiedi più di una volta »WTF ?! Chi ha inventato questo ?! «, dovresti dare un'occhiata alla prossima sezione.

Contra

Anche con Good Variable Names ™ (costruttore) i metodi con molti parametri (una misura soggettiva, che inizia nel mio caso a 3 ) implicano il problema di sapere come esattamente l'ordine dei parametri.

D'accordo: ci sono 2 invenzioni utili negli ultimi due decenni, essendo 1) l'IDE moderno ti guida lungo il percorso e 2) la maggior parte delle lingue ora ha parametri con nome.

Ma anche a parte questo problema (C # ha almeno dal 2010 i parametri denominati e Visual Studio è un ottimo esempio di IDE), rimangono due problemi:

a) devi capire cosa sta succedendo lì?

In caso di un modulo semplice, in cui hai solo alcuni controlli di base come »è valido il codice postale?« o qualcosa del genere, potresti utilizzare alcuni validatori standard del tuo framework che usi. Se è un oggetto write once and hopefully forget for a long time , non è necessaria una comprensione approfondita.

Ma se devi avere una comprensione dettagliata, dovresti rompere il contenuto degli oggetti lungo linee semanticamente appropriate. Senso: Supponete di avere un documento lungo, suddividerlo in sezioni con Good Class Names ™ e rifattorizzare il codice per prendere solo queste "sezioni" come parametri (btw. section1 , section2 non sono Good Variable Names ™).

Se disponi di un Entity che rappresenta un documento con 50 campi, puoi suddividerlo in 5 sezioni con 10 campi.

Il tuo metodo ora richiede 5 anziché 50 parametri

b) il problema di digitare

anche se ti occupi saltuariamente di un metodo del genere, devi digitare le cose più e più volte, il che è fastidioso.

Questo porta alla sezione successiva.

Neutro

Indipendentemente dalla domanda, se sia accettabile o meno avere tali "oggetti grassi" e tali "metodi larghi", dovresti dare un'occhiata all'automazione del lavoro, ovvero reflection .

Supponiamo che tu abbia un oggetto che rappresenta Form e uno che rappresenta Entity , la riflessione rende più facile il tuo inserimento delle informazioni dal primo al secondo.

tl; dr

Va bene? Sì. In alcune cornette potrebbe essere.

Ci sono modi migliori? Sì.

In entrambi i casi, dai un'occhiata a reflection .