Un'età compresa tra 0 e 17 causerebbe il fallimento della validazione? [chiuso]

Question

Un'età compresa tra 0 e 17 causerebbe il fallimento della validazione? [chiuso]

#1 da (3 voti)
#2 da (1 voti)

2

Recentemente ho fatto una domanda sulla convalida qui: Qual è il modo" migliore "per approvare la convalida dal punto di vista di un purista DDD?

Vedi il codice qui sotto, che ho preso in prestito da qui:

if (string.IsNullOrWhiteSpace(email) || email.Length > 100)
            throw new ArgumentException(“E-mail is invalid”);
        if (!Regex.IsMatch(email, @”^([\w\.\-]+)@([\w\-]+)((\.(\w){2,3})+)$”))
            throw new ArgumentException(“E-mail is invalid”);

Questo ha senso. Se l'utente immette un'email non valida, l'applicazione genera un'eccezione.

Ora, dire che stavo sviluppando un'applicazione per accettare le richieste di carte di credito. Per richiedere una carta di credito nel Regno Unito devi avere almeno 18 anni per legge (credo). Supponiamo che un utente inserisca una data di nascita che significa che sono 17. È un errore di convalida? 17 è un'età valida per essere. Mi rendo conto che -1 è un'età invalida; tuttavia che dire di 0-17?

Sul livello di presentazione ci sarebbe JavaScript in atto per impedire agli utenti di continuare se hanno meno di 18 anni, tuttavia dire che un utente è riuscito a raggiungere il livello del dominio perché JavaScript è stato disabilitato sul browser o lo sviluppatore del livello di presentazione / application layer non è riuscito a imporlo correttamente.

c# domain-driven-design validation

posta w0051977 15.10.2017 - 14:32

fonte

2 risposte

1

Un buon esempio. Vorrei utilizzare una combinazione delle tecniche della tua domanda precedente.

Potresti rendere Age un nuovo tipo di valore che non può essere inferiore a 0. (sebbene la data di nascita sia probabilmente migliore in tutto questo particolare esempio)

Il modulo che l'utente inserisce ha una sua logica di presentazione separata per aiutare l'utente a riempirlo correttamente.

L'oggetto dominio dovrebbe verificare i requisiti aziendali nel metodo di vendita e generare eccezioni (o eseguire la logica alternativa appropriata) quando falliscono.

Ciò consente di raccogliere applicazioni che non rispettano la logica aziendale. Potresti aver bisogno di questi per la segnalazione o se l'elaborazione è ritardata o se la logica cambia. cioè inviare e-mail ai giovani richiedenti che offrono un supplente.

risposta data 15.10.2017 - 15:09

fonte

Leggi altre domande sui tag c# domain-driven-design validation

In che modo SCRUM può essere applicato a un team responsabile di vari progetti? Come evitare riferimenti circolari in OOP Javascript?

score 3 · Accepted Answer

I believe it should throw an exception because it would mean the presentation layer has not done it's job properly

Sebbene il lancio possa essere ancora valido, non si tratta necessariamente di un'interfaccia utente.

Nel modo in cui stai formulando la domanda, stai postulando che un utente sconosciuto e minorenne sta inserendo la data di nascita su un modulo di interfaccia utente per la richiesta di credito.

Ma cosa succede se l'utente (minorenne) è già noto al sistema, ad es. perché hanno una carta bancomat o un conto di risparmio (e presumiamo che il sistema conosca la data di nascita).

E ora fanno domanda per una carta di credito come utente registrato. Se conosci già la loro data di nascita, non ti aspetteresti che compili un modulo con la loro data di nascita.

Quindi, in questo caso, la loro domanda di credito non rispetterebbe le regole commerciali per l'emissione di carte di credito. Pertanto, in conformità con la risposta di @ Ewan, a seconda di ciò che l'azienda desidera , in primo luogo non dovresti accettare la loro richiesta di credito o accettarla e successivamente negare applicazione in elaborazione.

Would an age between 0 and 17 cause validation to fail?

e

@Andy, just following the fail fast principle preventing unnecessary roundtrips to server. The domain model will do the validation as well.

Sembra che tu stia pensando a questo come validazione di base del modello.

Tuttavia, considero ciò di cui si parla come regola aziendale per una specifica funzione aziendale (emissione di carte di credito), piuttosto che come convalida di base del modello. (ad esempio, solo perché questo cliente non può ottenere una carta di credito non significa che il modello non è valido.)

In breve,

Esegui ciò che l'azienda desidera sia in termini di regole aziendali che di esperienza sull'interfaccia utente. Ad esempio, è un errore veloce (delle applicazioni di credito) guidato da interessi commerciali o è un'idea di programmatore?

In genere, fallire rapidamente significa acquisire errori di digitazione che l'utente può immediatamente risolvere. Quindi, per una data non valida o non valida (ad esempio il 31 febbraio 00/00/0000) ha senso, anche se probabilmente per una data valida che è minorenne per alcune operazioni non lo è.

Metti le regole aziendali nel posto più appropriato per loro ai fini della manutenibilità a lungo termine del software. (In questo caso da qualche parte lungo il percorso in cui vengono emesse le carte di credito.) Se si duplicano le regole aziendali nell'interfaccia utente per scopi di fail veloce, si dovrebbe essere consapevoli del fatto che lo si sta facendo.

Fare copie di codice è considerato WET (rispetto a DRY). (Fare copie dei dati è considerato cache o denormalizzazione, a seconda del contesto.) In generale quando facciamo copie (codice o dati), stiamo scambiando le prestazioni per complessità. La complessità, essendo soggetta a errori, richiede più test fin da subito. Inoltre, le copie ostacolano la manutenibilità poiché possono andare fuori sincrono tra loro.