Quando le regole aziendali influenzano la presentazione in MVC

8

Si suppone che il modello di progettazione MVC sia in grado di separare le regole aziendali dalla presentazione.

Ma a volte le regole aziendali influenzano la presentazione. Qual è il modo migliore per affrontare questo? È quello che dovrebbe essere usato un ViewModel?

Ad esempio, tornando alla mia applicazione di libreria inesistente, un bibliotecario sta analizzando i libri restituiti. Il sistema indica che un libro è in ritardo e applica una multa a tale utente.

Alcuni dipendenti potrebbero avere la sicurezza di ignorare quella multa in base a determinate condizioni.

Il livello di presentazione della mia applicazione di libreria dovrà consentire al dipendente di impostare la multa su 0 o fare clic su un pulsante per sovrascrivere la multa.

Tuttavia, i dipendenti che NON hanno la sicurezza per farlo dovrebbero vedere il costo come input disabilitato o solo di lettura.

Tieni presente che la sicurezza potrebbe non essere l'unica regola aziendale . Questo è solo un esempio. Ad esempio, la mia applicazione potrebbe avere impostazioni di configurazione configurate da qualche parte che rendono inutile un campo su uno schermo, ecc.

Sebbene il codice possa consentire a chiunque di modificare l'ammenda e quindi mostrare un messaggio di convalida, non è una buona esperienza utente.

Che cosa è una buona pratica per realizzare questo? Le opzioni che posso pensare (usando ASP.NET MVC) sono:

  1. Chiedi alla vista di controllare la regola aziendale e disabilitare o abilitare il campo.

  2. Utilizza una funzione HTMLHelper che implementa la presentazione per il campo fine e verifica che la funzione di supporto controlli la regola aziendale.

  3. Chiedi al controller di controllare la regola aziendale e utilizzare una vista diversa.

  4. Chiedi al controller di controllare la regola aziendale e imposta una proprietà nel ViewBag che indica se il campo è abilitato.

  5. Utilizza un ViewModel controlla la regola aziendale e imposta le informazioni che indicano che il campo è abilitato.

Opzioni 1 & 2 fa in modo che il livello di presentazione debba eseguire la convalida delle regole aziendali e ciò confonde le cose.

L'opzione 3 causerà la duplicazione degli sforzi in quanto ora hai due viste definite.

Opzione 4 & 5 richiede che il livello di presentazione sappia che il campo potrebbe essere abilitato o disabilitato, ma non PERCHÉ. Penso che mi piacciono i 4 o i 5 migliori.

Ci sono altre opzioni a cui non sto pensando?

    
posta scott.korin 18.02.2012 - 17:11
fonte

1 risposta

3

Penso che la tua opzione numero 5 sia la migliore, ma con qualche ritocco:

Il tuo ViewModel dovrebbe avere una proprietà che indica se i dati possono essere aggiornati o meno. Forse una proprietà booleana "CanOverrideLateFine".

Qualunque cosa stia creando ViewModel (il tuo Controller, o più probabilmente un servizio aziendale a cui il Controller è delegato) è responsabile della valutazione delle regole aziendali e dell'impostazione di tale proprietà. Non lo stesso ViewModel.

Il View esaminerà quindi la proprietà "CanOverride" e determinerà come eseguire correttamente il rendering per l'utente. potrebbe essere semplice quanto abilitare o disabilitare un campo modulo, ma potrebbe essere qualcosa di completamente diverso (magari non rendere il campo o fornire un elemento visivo completamente diverso).

    
risposta data 18.02.2012 - 21:58
fonte

Leggi altre domande sui tag