Lo scopo principale delle best practice come DRY non è quello di rendere le cose più facili per tu , ma di rendere le cose più facili per future tu ( e per le altre persone che lavoreranno al progetto). Si preoccupano meno del processo di codifica e di più del risultato finale. Naturalmente, ciò non significa che il processo non sia importante, ma è una preoccupazione per le metodologie di sviluppo e la pianificazione aziendale (che è anche necessario bilanciare)
A tale riguardo, riscrivere la logica per il server non viola DRY - ciò che potrebbe violare DRY è mantenere sia le implementazioni lato client che lato server e utilizzarle entrambe. La riscrittura stessa crea lavoro per te, ma se una volta fatto si finisce con un'applicazione migliore può essere utile. Mantenere entrambe le versioni significa che devi mantenerle sincronizzate (le modifiche a una devono essere replicate nell'altra), il che rende il progetto più difficile da mantenere. È un problema per il tuo futuro.
Ora, come ha detto Ddyer nell'altra risposta, se invii i dati dal client al server, il server deve convalidarli. Quindi la domanda principale è:
Quanto è complesso convalidare il progresso rispetto al calcolo del progresso?
Se convalidare il progresso è complesso come calcolarlo, dovrai mantenerli sincronizzati, il che rende il progetto più difficile da mantenere. È diverso dal dover sincronizzare le due implementazioni di calcolo (Più facile perché i bug compariranno prima quando il codice di validazione rifiuta il progresso che dovrebbe essere OK. Più difficile perché non c'è più il mapping quasi-uno-a-uno tra le logiche), ma è ancora un problema per il futuro.
D'altra parte, se convalidare il progresso è molto più semplice del calcolo, potresti considerare calcolare nel lato client e inviare al lato server. Dovresti, ovviamente, prendere in considerazione cose come:
- Il calcolo del progresso richiede molte interazioni cliente / utente? Se il server, per esempio, dovrà contattare il cliente per porre domande agli utenti, e avrà bisogno di queste risposte prima che l'utente possa procedere, tutto questo ping-pong può essere prevenuto se i calcoli vengono eseguiti sul lato client.
- Se il calcolo dell'avanzamento è principalmente per visualizzarlo all'utente e ne hai solo bisogno sul lato server per scopi di registrazione, può essere più semplice e produrre risultati migliori affinché il client esegua il calcolo stesso invece di avere la query server ogni volta che desidera aggiornare la visualizzazione dell'avanzamento.
- Quanto lavoro è necessario reimplementare la logica rispetto all'implementazione dell'API per il trasferimento tra client e server?
- Vuoi consentire a clienti di terze parti? In tal caso, se la logica è sul lato client, sarà necessario reimplementarla ...
E così via - il punto è che questi dovrebbero essere considerati solo se la logica di validazione è semplice (il che significa che probabilmente si possono fare molte modifiche alla logica di calcolo senza dover cambiare la logica di validazione), dal momento che bisogna sincronizzare la logica di convalida complessa con una logica di calcolo complessa renderà il progetto più difficile da mantenere.