DRY vs Sicurezza e manutenibilità con MVC e View Models

Question

Mi piace lottare per DRY, e ovviamente non è sempre possibile. Tuttavia, devo grattarmi la testa su un concetto che sembra abbastanza comune in MVC, quello del "View Model".

Il modello di vista è progettato per trasmettere solo la quantità minima di informazioni alla vista, sia per problemi di sicurezza, manutenibilità e test. Ho capito. Ha senso.

Tuttavia, da un punto di vista DRY, un modello di vista duplica semplicemente i dati già esistenti. Il modello di visualizzazione può essere temporaneo e utilizzato solo come DTO, ma fondamentalmente stai mantenendo due versioni diverse dello stesso modello che sembrano violare il principale di DRY.

I modelli Do View violano DRY? Sono un male necessario? Fanno più bene che male?

Answer 1

Questo è stato portato più e più volte. Non solo è un ingannatore piuttosto sostanzioso, ma la risposta è soggettiva e polemica. I ViewModels sono una risposta al DDD e al concetto di ignoranza della persistenza.

Dire che non utilizzare ViewModels è male significa ignorare che Django e Rails e la maggior parte dei framework PHP ORM/MVC non si preoccupano affatto di questi concetti. Vuoi che qualcuno ti dica che tutti quegli altri linguaggi e framework stanno "facendo qualcosa di sbagliato?".

Se si desidera utilizzare ViewModels dipende al 100% da quali stili di architettura si intendono e quali sono gli obiettivi dell'applicazione.

Questo è come chiedere è trascinare e rilasciare GridViews in un'app WebForm appropriata? Dipende da molte cose

C'è anche un equivoco su DRY che hai qui. Le classi Proxy da un servizio WCF violano DRY? ViewModel contiene la logica? L'obiettivo principale di DRY è di non avere una logica duplicata con uno scopo significativo. Un paio di DTO che condividono lo shaprod dell'oggetto lo violano?

Il principio DDD dei contesti limitati potrebbe essere una buona lettura. Se un oggetto ShoppingCart ha bisogno di funzionare in modo diverso in un magazzino o in un sito Web di ecommerce, significa che devi condividere i tipi? Cosa succede quando l'unica funzionalità condivisa sta totalizzando un prezzo (prezzo + tasse + spese di spedizione)? Crei una classe base solo per questo aumentando l'accoppiamento? Quali sono i compromessi in termini di tempo/costi/manutenzione per essere 100% DRY per un metodo semplice come GetTotal(). Violare la DRY quando ha senso diminuire effettivamente la complessità e il costo complessivo della manutenzione della base di codice?

Mi dispiace rispondere con così tante domande, ma spero che ora sia possibile vedere le sfumature e le complessità della domanda che hai chiesto. ;)

Answer 2

Si potrebbe anche notare che non utilizzare i modelli di visualizzazione sarebbe una violazione del principio di responsabilità singola - la vostra entità non dovrebbe essere inquinata da problemi di interfaccia utente.

Penso anche che il valore reale dei modelli di visualizzazione non diventi necessariamente evidente nella versione 1.0 dell'applicazione. Ti ringrazierai quando lavorerai sulla versione 2.0 quando ripenserai completamente a come funziona il tuo back-end, ma non dovrai portare tali modifiche al livello vista.