A. Where can I place the validation?
Indipendentemente dal tuo design, ci sono due posti in cui va il codice di validazione:
- Vicino all'input
- Vicino a
Metti la validazione vicino a input in modo che tu possa mostrare all'utente l'errore velocemente e ottenere una correzione tempestiva. Inoltre, per comprendere bene il contesto degli utenti.
Metti in pratica la validazione per proteggersi dalle molte cose selvagge e meravigliose che possono cambiare i dati da quando è stato convalidato per la prima volta.
In alcuni progetti questi due posti sono lo stesso posto. Questo può andare bene fino a quando l'applicazione non cresce.
Comprendi che la convalida è richiesta solo quando il sistema di tipi non è abbastanza specifico per le tue esigenze. Se un metodo può utilizzare qualsiasi int allora non è necessaria alcuna convalida oltre il sistema di tipi. Se un metodo può utilizzare qualsiasi int non negativo, allora è necessaria la convalida se la tua lingua non ha int unsigned.
B. In which layer?And how(design) can I enrich the POCOs defined in CoreLayer with that validatons ?(I guess validation fits better in businesslayer since they represent business rules)
Non tutta la convalida è una regola aziendale. A volte è una regola per le applicazioni. Ad esempio se l'azienda non si cura se l'ID auto è negativo ma l'applicazione lo fa, forse a causa del DB, quindi non è l'azienda che ha creato questa regola. Va bene. È ancora importante convalidare. Ma non è una regola aziendale.
PresentationLayer
Contains all the WinForms to retrieve information=> generating POCOs and ideally I want to validate the user input. These POCOs are latter stored in DB
Sembra che il livello di presentazione generi l'auto. Potremmo far rispettare le regole dell'ID qui semplicemente non creando mai un ID negativo o zero. Tuttavia, poiché Id ha un setter pubblico, tutto ciò che tocca Car può rovinarlo. Se lo hai cambiato in privato, passando a utilizzare un costruttore per impostare l'ID sarebbe immutabile e non dovremmo mai più controllarlo. Se lo facessi, potresti mettere la validazione nella classe Car stessa. Diventa parte del tipo di auto. Se non lo fai, dovrai controllarlo nuovamente prima di inserirlo nel DB.
Il Name potrebbe avere una vera regola aziendale come "nessuna parolaccia". Questo è probabilmente l'utente inserito. Vorresti informare l'utente del problema sullo stesso schermo in cui hanno inserito la parolaccia. Anche in questo caso, è possibile passare all'utilizzo di un costruttore per impostare un nome immutabile e tutti gli oggetti di tipo Car avrebbero nomi senza parole. Altrimenti vorrai assicurarti di ricontrollarlo prima di usarlo per assicurarti che qualcos'altro non lo abbia incasinato.
Il livello di presentazione dovrà gestire i fallimenti di validazione se solo per recuperare da essi. Probabilmente dicendo all'utente "non funzionerà perché
risposta data
30.05.2018 - 16:05