DDD e validazione

Question

Ho cercato in giro su StackOverflow per un post simile sul lato client e sì, c'erano alcune discussioni su ciò che sto per chiedere, ma ho deciso di iniziare una nuova discussione.

Supponiamo di avere un'applicazione che utilizza il modello di dominio modello, DDD e un sacco di altri modelli di progettazione. Supponiamo di avere un certo numero di soluzioni come di seguito elencati:

• Solution.Model
• Solution.Repository
• Solution.Services
• Solution.Presentation
• Solution.UI.Web

Il livello dell'esperienza utente sarà Solution.UI.Web e supponiamo che sarà un'applicazione WebForms ASP.NET. come si applica la validazione lato client?

Ci sono da considerarsi una serie di cose:

In primo luogo, non avremmo dovuto colpire l'application server/database (s) per tornare eventuali errori di convalida al cliente, potremmo comunque implementare anche la validazione lato server, ma avremo bisogno anche della validazione lato client.

In secondo luogo, noi non vogliamo attuare le regole di convalida sullo strato esperienza dell'utente. Questo perché se la tua applicazione è una WebApp e poi decidi di creare anche un client WinApp, dovrai implementare nuovamente le regole di convalida -> incubo di manutenzione.

Un approccio semplice sarebbe implementare la logica di convalida con gli oggetti ViewModel (viste appiattite delle entità di dominio che verranno inviate al client) e quindi convalidare tali oggetti prima di colpire i server dell'applicazione/database.

Un altro approccio, quello che ho visto usato molte volte in diverse applicazioni, è quello di generare solo un insieme di messaggi di errore di convalida e inviare tale raccolta al cliente. va bene, ma c'è un problema. solo un semplice messaggio di riepilogo degli errori di validazione non funzionerà, specialmente se si dispone di un modulo per l'immissione di dati di grandi dimensioni.

Ora il framework ASP.NET MVC rende la vita molto più semplice. puoi utilizzare EF + DataAnnotations e il framework MVC Scaffolding può fare la maggior parte del lavoro per te. ma questo è il caso se vuoi creare un'applicazione MVC e implementare la tua logica di validazione con jquery e java script.

Ma se fosse necessario un approccio più generico per implementare un framework di convalida che può essere utilizzato e utilizzato in diverse applicazioni, ad esempio WinForms e WebForms?

Giusto per chiarire, quello che sto cercando è un insieme di modelli/principi e/o tecniche/strutture di progettazione per implementare un framework di validazione che può essere implementato con il tuo modello di dominio e quindi essere applicato alle tue applicazioni client. AND -> non voglio solo restituire una raccolta di messaggi di errore relativi alle stringhe o qualsiasi altra cosa, voglio poter aggiornare i miei controlli con associazione a dati (TextBox, ComboBox, DateTimePicker, ecc.) In caso di errore di validazione in modo che il livello dell'esperienza utente sarebbe più intuitivo (se lo vorrai).

Ho visto alcune implementazioni e framework qua e là, e ho usato la convalida lato client ASP.NET MVC per un po 'di tempo. quindi la mia risposta non ha nulla a che fare con la convalida MVC o JavaScript.

P.S Se potessi menzionare link di riferimento, libri, articoli, progetti di esempio e/o includere frammenti di codice sarebbe fantastico.

TNX, Armin [:

Answer 1

io non ho incontrato una soluzione di convalida onnicomprensivo. Una ragione di ciò è che la logica di convalida può essere leggermente diversa a seconda del livello dell'applicazione. Ad esempio, non tutte le regole applicate dal livello del dominio possono essere applicate sul lato client e quindi ci saranno sempre casi in cui la convalida del lato client può passare e tuttavia è ancora necessario visualizzare un messaggio di convalida propagato dal livello del dominio.

Tuttavia, il modello di convalida in ASP.NET MVC è estensibile ed è possibile estenderlo per supportare regole di convalida aggiuntive o per eventificare un framework di convalida diverso da DataAnnotations. Here è un esempio di integrazione del blocco di convalida della libreria Enterprise con ASP.NET MVC, tuttavia, come indicato dall'articolo, la convalida del lato client non è stata implementata. Un altro approccio potrebbe essere quello di utilizzare gli attributi DataAnnotations nel livello del dominio. Lo spazio dei nomi DataAnnotations non è legato a ASP.NET MVC.

La sfida in questi approcci è tuttavia quella di propagare le regole di convalida dagli oggetti dominio per visualizzare i modelli. In teoria, è possibile estendere AutoMapper in modo tale che le regole di convalida da un modello di dominio vengano trasferite per visualizzare le classi del modello, tuttavia i costi di implementazione e manutenzione potrebbero superare i vantaggi di questa soluzione.

Il quadro Fluent Validation può essere utilizzato come punto di partenza per una soluzione di convalida onnicomprensiva. Ci sono molti examples di usare questo framework con ASP.NET MVC.

Answer 2

In DDD, il dominio è in genere autoconvalidante. In altre parole, gli oggetti non possono essere in uno stato non valido. Gli oggetti valore aiutano molto qui. Semplicemente incapsulano le regole di formattazione. Ad esempio è possibile avere classe Codice postale che è garantito per essere sempre ben formato. Come ulteriore responsabilità, può avere un metodo statico come ZipCode.TryParse o ZipCode.Validate che accetta stringhe arbitrarie come parametri e convalida. In questo modo la logica di convalida è concentrata in un unico punto. Se gli oggetti del dominio sono accessibili direttamente dall'interfaccia utente, non è necessario duplicare questa logica da nessun'altra parte. Questo è il caso dei fat client (Windows Forms, WPF). Sfortunatamente non è possibile evitare alcune duplicazioni per i client Web quando è necessario eseguire la convalida senza eseguire il round trip sul server.

Answer 3

È necessario incapsulare la logica di convalida in classi semplici che rappresentano la conoscenza del dominio.

Ne scrivo nel mio post del blog primitive obsession. Ecco come il controller ASP.NET MVC può apparire come se si crea tali classi:

public class CustomerController : Controller 
{ 
    [HttpPost] 
    public ActionResult CreateCustomer(CustomerInfo customerInfo) 
    { 
     Result<Email> emailResult = Email.Create(customerInfo.Email); 
     Result<CustomerName> nameResult = CustomerName.Create(customerInfo.Name); 

     if (emailResult.Failure) 
      ModelState.AddModelError("Email", emailResult.Error); 
     if (nameResult.Failure) 
      ModelState.AddModelError("Name", nameResult.Error); 

     if (!ModelState.IsValid) 
      return View(customerInfo); 

     Customer customer = new Customer(nameResult.Value, emailResult.Value); 
     // Rest of the method 
    } 
} 

Non c'è bisogno di utilizzare le annotazioni, perché in sostanza, vi incoraggio a duplicare la logica di convalida.

confrontare questi esempi di codice:

• With primitive obsession
• Without primitive obsession