Come progettare le funzioni quando devono lavorare con dati "normalizzati" e "non normalizzati"

Question

Come progettare le funzioni quando devono lavorare con dati "normalizzati" e "non normalizzati"

#1 da (2 voti)
#2 da (0 voti)

0

Sto lavorando su un'applicazione web che memorizza identificatori, come nomi utente e indirizzi email in forma "normalizzata" e moduli "non normalizzati", per una serie di motivi. Ad esempio, un nome utente "John_Smith" verrebbe normalizzato in "johnsmith".

Tuttavia, alcune delle interfacce utente devono funzionare con la rappresentazione normalizzata, le altre non hanno bisogno di farlo. Continuando con lo stesso esempio, una visita alla pagina /user/John_Smith , /user/johnsmith o /user/jOhnsMith dovrebbe restituire le stesse informazioni, quindi sarebbe necessaria la normalizzazione. D'altra parte, un endpoint API (ad esempio /api/update/?user=John_Smith&value=20 ) non avrebbe bisogno di farlo.

Quindi, nel codebase ci sono alcune funzioni che normalizzano i nomi utente e altri che non:

class UserManager {
  getUserInfo(username) {
    normalized_username = normalize(username)
    // do stuff with the normalized value
    return info
  }

  updateValue(username, amount) {
    // do stuff, without normalization
    return info
  }

  // ...
}

Questo sembra molto incoerente, c'è un modo migliore?

L'unico modo migliore che potrei pensare è quello di richiedere che i chiamanti normalizzino gli argomenti della funzione prima di passarli e che tutte le funzioni funzionino esclusivamente su tali input normalizzati. (Tuttavia ucciderebbe il rigore dell'API, tuttavia, non è un requisito importante.)

_{(Sono consapevole del vero problema, è il fatto che le classi di entità non esistono nella base di codice. Se fossero state lì, sarebbe semplicemente una questione di Users.find('username', input_user) o Users.find('normalized_username', normalize(input_user)) . Tuttavia, scrivere un mapper database-to-class non è realmente possibile in questo momento).}

language-agnostic functions design-patterns

posta user2064000 31.12.2016 - 18:23

fonte

2 risposte

Leggi altre domande sui tag language-agnostic functions design-patterns

È una cattiva idea usare un avvertimento Beta su un'applicazione web onworking? Come viene controllato il percorso dei dati tra ALU e registri?

score 2 · Answer 1

Consiglierei le classi wrapper attorno alle stringhe, quindi hai NormalizedName e NonNormalizedName classi che contengono una stringa. In questo modo eviti di mischiarli e le firme delle funzioni segnaleranno chiaramente quale versione si aspettano.

Raccomando anche di utilizzare esclusivamente NormalizedName nella logica aziendale.

score 0 · Answer 2

Quando ho qualcosa che potrebbe essere rappresentato in più forme, in genere mantengo una proprietà impostabile ed espongo un'altra proprietà per il diverso formato (di solito lo faccio in termini di nomi, come CommonName, FormalName, ecc.): / p>

class User
{
    public string UserName { get;set;}
    public string NormalizedName {
        get {
            return normalize(Username);
        }
    }   
}

quindi usalo in questo modo:

var user = new User(username)
// do stuff with user.Username (non-normalized, as-is)
// do stuff with user.NormalizedName

Detto ciò, la citazione di Robert sull'uso di un ID è azzeccata.