Che aspetto ha il principio DRY in ASP.NET MVC?

Question

Continuo a sentir parlare del principio DRY e di come sia così importante in ASP.NET MVC, ma quando faccio ricerche su Google non mi sembra di capire esattamente come si applica a MVC.

Da quello che ho letto non è proprio la copia & amp; incolla odore di codice, che pensavo fosse, ma è più di questo.

Qualcuno di voi può dare un'idea di come potrei usare il principio DRY nella mia applicazione ASP.NET MVC?

Answer 1

• utilizza gli attributi di filtro per gestire gli aspetti (autenticazione, navigazione, breadcrumb, ecc.)
• usa un layer supertype (applica filtri comuni a livello di controller, vedi < a href = "http://code.google.com/p/mvccontrib/source/browse/trunk/src/MVCContrib/ConventionController.cs" rel = "nofollow noreferrer"> mvccontrib per un esempio )
• scrivi actionresults personalizzati (come in mvccontrib - per esempio ne abbiamo creato uno chiamato logoutresult che fa semplicemente un FormsAuthentication.Logout()
• usa una convenzione per visualizzare i nomi
• soprattutto - tieni le azioni del controller stupide , cerca opportunità di riutilizzo nei servizi

Answer 2

DRY significa solo " Non ripetere te stesso " ;. Assicurati che quando scrivi il codice, lo scrivi solo una volta. Se ti ritrovi a scrivere funzionalità simili in tutte le tue classi Controller, crea una classe controller di base che ha la funzionalità e quindi eredita da essa, oppure sposta la funzionalità in un'altra classe e chiamala da lì invece di ripeterla in tutti i controller.

Answer 3

Non ripetere te stesso. Può applicarsi a molti aspetti diversi della programmazione. Il livello più basilare di questo è prevenire l'odore del codice. Non ho usato ASP.NET, quindi non posso essere specifico ad esso e MVC.

• In C ++ Templating prevede più copie della stessa funzione.
• In C void * i puntatori possono essere usati in modo simile, ma con grande cura.
• Ereditare da un'altra funzione consente la funzione consente ad altre funzioni di utilizzare la stessa base di codice senza dover copiare il codice.
• La normalizzazione dei dati in un database riduce al minimo i dati ridondanti. Anche aderendo al principio DRY.

Quando vai oltre un " pensato " in un progetto. Chiediti.

1. Ho già scritto questo codice?
2. Questo codice sarà utile altrove.
3. Posso salvare la codifica partendo da una classe / funzione precedente.

Answer 4

DRY non è specifico per nessuna una tecnologia. Assicurati solo di guardare le tue classi dal punto di vista della funzionalità (nemmeno da una vista del codificatore copia / incolla) e vedere dove si verifica la duplicazione. Questo processo probabilmente non avverrà in una sola seduta e noterai la duplicazione solo dopo aver esaminato il tuo codice diversi mesi dopo l'aggiunta di una nuova funzionalità. Se hai dei test unitari, non dovresti avere paura di rimuovere quella duplicazione.

Answer 5

Un vantaggio di MVC rispetto al non ripetersi è che il controller può svolgere attività comuni a tutte le pagine di una classe. Ad esempio, la convalida su determinati tipi di richieste dannose o la convalida dell'autenticazione può essere centralizzata.

Answer 6

DRY non dovrebbe essere applicato solo al codice, ma alle informazioni in generale. Stai ripetendo cose nel tuo sistema di compilazione? Hai dati che devono essere spostati in un file di configurazione comune, ecc.

Answer 7

Bene, l'esempio più comune che posso dare su DRY e UI sta usando cose come MasterPages e UserControls.

MasterPages ti assicura di aver scritto tutto il codice HTML statico una sola volta.

I controlli utente garantiscono la riusabilità del codice. Ad esempio, avrai molte forme che fanno cose di base come CRUD. Ora, idealmente, desideriamo che tutti gli utenti vedano pagine diverse per Crea e Aggiorna, sebbene i campi dei moduli in entrambi saranno quasi gli stessi. Quello che possiamo fare è combinare tutti i controlli comuni e metterli in un controllo che può essere riutilizzato su entrambe le pagine. Questo assicura che non stiamo mai ri-digitando (o incollando) lo stesso codice.

DRY è particolarmente importante in MVC a causa dell'aumento del numero assoluto di file per svolgere la stessa attività.

Answer 8

Sembra che ci sia un malinteso secondo cui tutto in un modello di dominio deve essere copiato come un modello di vista speciale. Puoi avere modelli di dominio come modelli di dominio, ma i modelli di visualizzazione possono essere qualcosa che non sanno nulla di specifici di dominio ed essere più generici. Ad esempio:

Classi del modello di dominio: Account, Asset, PurchaseOrder

Visualizza modello: elenco, tabella, tupla, SearchFormBackingModel: opzioni selezionate, opzioni di output, ecc. La vista stessa potrebbe essere molto più specifica dell'implementazione della vista.

La Tupla / Dittonaria / Mappa potrebbe essere mappata su singole istanze di Account, Asset e OrderOrder ma una Tabella potrebbe essere utile per una raccolta di esse ecc. Hai ancora MVC ma hai dati di sessione, non pronti per la transazione ma in una vista modello senza necessariamente che violi le regole del tuo modello di dominio, che è dove dovrebbero andare le regole. In questo modo saranno meno anemici e anti-pattern. Puoi passare queste regole in anticipo e usarle lì o semplicemente dietro o entrambe a seconda di come il sistema legge dai client ecc.