ASP.NET MVC - gli MVC M, V e C dovrebbero essere esplicitamente a conoscenza delle entità di dominio?

Naviga le tue risposte
8

Poiché questa domanda sembra essere piuttosto soggettiva, la sto postando qui.

Diciamo che stai scrivendo la tua versione di Stackoverflow usando ASP.NET MVC, quindi ci sono classi come Question , Answer , User , ecc. Dato che sei pigro, hai deciso di usare l'entità struttura. Quindi, tutte le classi menzionate sopra hanno proprietà di navigazione: Question conosce il suo Answer s, Answer conosce User chi lo ha pubblicato, ecc.

Hai letto molti libri di Martin Fowler, quindi sicuramente avrai un livello di servizio per implementare tutta la logica aziendale lì. Utilizzerai ASP.NET MVC solo per l'interfaccia utente e la funzionalità relativa alla logica dell'applicazione.

Ci sono 2 domande:

  1. Esponi direttamente oggetti di Question , Answer e altri ai controller?
  2. Farai lo stesso per le viste?

Fondamentalmente non fornirò una API REST alla mia applicazione, né sono troppo prudente per avere solo paure come "hey, MY VIEW è a conoscenza di cosa sia Question , non so se è cattivo o no, semplicemente non mi piace! ".

Sono particolarmente curioso del caso in cui la classe Question ha un campo come TimePosted e vincoli la tua vista PostNewQuestion a quella classe. So che nel caso in cui non leghi quel campo a nessun controllo sulla pagina, non verrà pubblicato, quindi avrò il campo impostato su null quando ho ottenuto l'oggetto sul mio controller. È considerato buono o è una cattiva idea? 2 approcci opposti che sto pensando sono "usare DTO / ViewModels ovunque" e "wtf, meno lezioni è sempre meglio!"

Quale pensi che sia un approccio giusto ? (So che non c'è una risposta diretta, quindi la domanda in effetti è "cosa dovremmo considerare per decidere se utilizzare DTO / ViewModels / Qualcos'altro è buono per l'architettura della sua app?")

Si noti inoltre che stiamo prendendo in considerazione un clone di StackOverflow molto semplificato, quindi:

  1. È un progetto solo web (non esponiamo l'API REST o qualsiasi altra cosa)
  2. Ci sono utenti, domande, risposte, tag e funzionalità di ricerca (nessuna logica aziendale in sospeso)
  3. Ci sono circa 100 utenti attivi al giorno (nessun requisito di rendimento speciale)
  4. Il codice dovrebbe essere leggibile e non ci dovrebbero essere sorprese o luoghi di particolare interesse nel caso in cui un nuovo membro si unisca al team di sviluppo.

Potresti anche esprimere la tua opinione nel caso in cui uno dei primi 3 punti venga modificato: "il cliente ora vuole che il nostro servizio consenta 10000 utenti simultanei" o "ora dobbiamo consentire a ogni singolo utente di pubblicare una volta ogni 15 minuti" , ecc.

Grazie!

    
posta Andrey Agibalov 02.12.2011 - 21:45
fonte

1 risposta

3

Non ho lavorato molto con MVC, tuttavia ho lavorato molto con MVVM e questo è il mio punto di vista:

Question , Answer e User sono tutti oggetti dati. È giusto che si conoscano l'un l'altro, ma non dovrebbero sapere nulla al di fuori del livello dell'oggetto dati, come Views, Controllers, ViewModels, ecc.

In un mondo ideale, la tua vista fa riferimento solo ai modelli. Potrebbero sapere del controller, ma non dovrebbero fare riferimento direttamente. ViewModel conosce solo altri modelli. Il controller conosce modelli e ViewModels. Non interessa affatto alla vista, anche se fornisce la vista con ViewModels o Models.

Quindi i tuoi oggetti finiscono in questo modo:

  • Gli

    M odori sono disponibili in due varianti: Models e ViewModels.

    • I modelli sono semplici oggetti dati che esistono semplicemente per contenere i dati e sono generalmente un riflesso dei dati del database. Non accedono al database o contengono alcun tipo di logica aziendale che non è correlata a loro.
    • ViewModels sono oggetti dati che contengono dati di cui ha bisogno la vista, non necessariamente ciò di cui il database ha bisogno. Possono contenere modelli, sebbene i modelli non contengano ViewModels.

  • C i controllori contengono la tua logica aziendale. Controllano le chiamate di accesso ai dati, creando Modelli / ViewModels per passare alla Vista, logiche di business avanzate come permessi, ecc. Fondamentalmente controllano l'intero livello del codice.

  • V iews è appena usato per fornire agli utenti un'interfaccia user-friendly. Accettano un ViewModel o un Modello e lo visualizzano in un modo che sembra piacevole per l'utente.

risposta data 02.12.2011 - 22:30
fonte

Leggi altre domande sui tag

Quali convenzioni di denominazione utilizzate per le classi di php? [chiuso] Esiste un insieme quasi standard di attributi per annotare sicurezza dei thread, immutabilità ecc.?