2010-10-19 6 views
15

Eventuali duplicati:
ASP.NET MVC - Linq to Entities model as the ViewModel - is this good practice?ASP.NET MVC: utilizzando le entità EF come viewmodels?

Is è OK per utilizzare le classi entità EF come visualizzare i modelli in ASP.NET MVC?

Cosa succede se viewmodel è il 90% lo stesso della classe di entità EF?

Diciamo che ho una classe Survey nel modello Entity Framework. Il 90% corrisponde ai dati richiesti per la visualizzazione per modificarlo. L'unica differenza rispetto a ciò che dovrebbe avere il modello di vista - è una o più proprietà da usare in esso (che sono richieste per popolare l'oggetto Survey perché la classe EF non può essere mappata direttamente su come sono rappresentate le proprietà (sotto-checkboxes, gruppi radio, ecc.))

Li passi con ViewData []? Oppure creare una copia della classe Survey (SurveyViewModel) con nuove proprietà aggiuntive (dovrebbe essere in grado di copiare i dati da Survey e tornare ad essa)?

Modifica: Sto anche cercando di evitare l'uso di Survey come proprietà SurveyViewModel. Sembrerà strano quando alcune proprietà Survey vengono aggiornate utilizzando UpdateModel o con binder predefinito, mentre altre (che non possono essere mappate direttamente all'entità) - utilizzando le proprietà personalizzate di SurveViewModel nel controller.

risposta

17

Mi piace usare Jimmy Bogard's approach di avere sempre una relazione 1: 1 tra una vista e un modello di vista. In altre parole, non utilizzerei i miei modelli di dominio (in questo caso le entità EF) come modelli di vista. Se ti senti come se steste facendo un sacco di lavoro di mappatura tra i due, è possibile utilizzare qualcosa come AutoMapper per fare il lavoro per voi.

+2

+1 per Automapper ... l'ho appena trovato, e lo adoro. – Martin

+1

ValueInjecter è molto meglio – mare

+1

Automapper mi ha cambiato la vita, è incredibilmente utile, soprattutto quando ci si abitua e si impara a mappare le proprietà di navigazione. – JBeagle

0

Nei progetti più grandi, di solito suddivido gli oggetti di business dagli oggetti di dati come questione di stile. È un modo molto più semplice per consentire al programma e al database di cambiare e influenzare solo il livello di controllo (o VM).

+1

I modelli di vista nel contesto MVC fanno riferimento a classi del modello progettate appositamente per essere utilizzate da una visualizzazione MVC. Solitamente sono solo una classe con proprietà che rappresentano un sottoinsieme del tuo modello di dominio. –

+0

Grazie per il feedback. Non ho usato MVC per alcuni anni. Penso che sia stata solo la prova e alcune lezioni della SM all'epoca. Quella parte deve essersi unita con MVVM. – tzerb

15

Alcune persone non amano passare queste classi del modello fino alla vista, specialmente perché sono classi legate al particolare ORM che si sta utilizzando attualmente. Ciò significa che stai vincolando strettamente il tuo framework di dati ai tuoi tipi di visualizzazione.

Tuttavia, ho eseguito questa operazione in diverse semplici app MVC, utilizzando il tipo di entità EF come Modello per alcune visualizzazioni fortemente tipizzate: funziona perfettamente ed è molto semplice. A volte vincite semplici, altrimenti potresti trovarti a impiegare molto impegno e codice per copiare valori tra tipi di modelli quasi identici in un'app in cui realisticamente non ti sposti mai da EF.

+0

così vero Simon .. – mare

+0

+1 questo, ottimo commento. – jhartzell

7

Si dovrebbero sempre avere i modelli di vista anche se sono 1: 1. Ci sono dei motivi pratici piuttosto che l'accoppiamento del livello del database su cui mi concentrerò.

Il problema con i domini, i quadri di entità, i modelli niberneti o linq 2 sql come classi di visualizzazione non è possibile gestire bene la convalida contestuale.Per esempio data una classe utente:

Quando una persona si iscrive sul tuo sito che ottengono uno schermo utente, è quindi:

  1. Convalida Nome
  2. Convalida Email
  3. Validare Password esiste

Quando un amministratore modifica il nome di un utente che ottengono uno schermo utente, è quindi:

  1. Convalida Nome
  2. Convalida Email

Ora esporre convalida contestuale via FluentValidation, DataAnnotations attributi, o addirittura personalizzato IsValid() metodi su classi di business e convalidare solo nome e indirizzo email modifiche. Non puoi È necessario rappresentare diversi contesti come modelli di viste differenti perché la convalida su tali modelli cambia in base alla rappresentazione dello schermo.

Precedentemente in MVC 1 è possibile aggirare il problema semplicemente non pubblicando campi che non si desidera convalidare. In MVC 2 questo è cambiato e ora ogni parte di un modello viene convalidata, pubblicata o meno.


Robert Harvey ha sottolineato un altro buon punto. In che modo il tuo Entity Framework utente visualizza una schermata e convalida la doppia corrispondenza della password?

+0

Si effettua un punto valido, ma se si stanno facendo corrispondenze di immissione password doppia, il modello di vista non è realmente 1: 1 con l'oggetto Modello entità, vero? –

+0

@Robert Harvey, si, dovrei usare un esempio diverso. La convalida della password esiste meglio perché su una modifica dell'amministratore non si cambia mai la password. Grazie, lo cambierò. – jfar

Problemi correlati