2009-02-27 36 views
9

Mi piace molto il modo in cui funziona ASP.NET MVC. Mi piacerebbe implementarlo su tutti i nuovi progetti web in futuro, ma mi sono imbattuto in un prototipo l'altro giorno in cui non ho trovato una buona soluzione, quindi ti chiedo, come potresti progettare un'app MVC che non si adatta al tipico pattern REST? Ad esempio, il prototipo che stavo progettando avrebbe diverse pagine, ma le pagine stesse non sono necessariamente legate a un modello di dominio. Per esempio, prendete un sito semplice registrazione, che potrebbe avere le seguenti pagine:ASP.NET MVC controller azioni design

  • /Default.aspx
  • /Register.aspx
  • /ThankYou.aspx

Di tanto in tanto, un tale il programma potrebbe richiedere una sezione di amministrazione per gestire dettagli come la moderazione delle iscrizioni o la revisione dei dati. In un ASP.NET web app di serie, mi permetto di aggiungere il seguente

  • /Admin/Default.aspx
  • /Admin/ListRegistrations.aspx
  • /Admin/ViewReports.aspx ...

sarebbe uno scostamento inaccettabile dal pattern MVC, in questo caso, di avere due controller come:

  • Home-> Indice
  • Home-> register
  • Home-> Grazie
  • Admin-> Indice
  • Admin-> ListRegistrations
  • Admin-> Reports

La mia frustrazione con questo è aggravato dal fatto che non esiste ancora una solida implementazione dei subcontrollori e delle aree. Sono a conoscenza del prototipo di "Aree" messo insieme da Phil Haack, ma non è molto maturo, e francamente, non sono sicuro che mi piaccia il modo in cui è impostato, ma non so davvero come mi piacerebbe per vedere che lavoro sia.

Immagino che quando penso a MVC tendo a pensare anche a REST e che le azioni del controller che rappresentano le pagine piuttosto che le entità o le azioni effettive non sono adeguate a me. Cosa ne pensi?

risposta

3

È sempre possibile combinare moduli Web ASP.NET con MVC.

Basta aggiungere

routes.IgnoreRoute("Pages/{*path}"); 

alla vostra tabella di routing e aggiungere pagine Web Form tradizionali per Pages cartella dell'applicazione.

+0

Questa è probabilmente l'idea migliore. Riesco a vedere la progettazione della parte utente del sito per utilizzare la roba MVC mantenendo la logica specifica dell'amministratore nei normali moduli Web. Grazie per avermi ricordato. – Chris

1

È possibile disporre di tutti i controller necessari; quella disposizione sembra ragionevole. Tieni presente che route non ha per mappare direttamente su {controller}/{action}, ma mantiene le cose semplici. Mi sembra soddisfacente, ad eccezione del fatto che probabilmente il Regista [GET] utilizza una vista diversa per registrarsi [POST]

+1

Immagino che la mia confusione/frustrazione con il modello inizi davvero a costruire quando si parla di uno scenario tipico in cui si potrebbero avere cartelle nidificate per separare le funzionalità. Ad esempio, un controller di prodotti per gli utenti, ma poi un controller Prodotti-> per la gestione dei prodotti. Dove? Come? – Chris

3

Un errore che i nuovi arrivati ​​in MVC fanno è raggruppare le azioni in un controller per motivi di visualizzazione. Nel tuo caso, invece di raggruppare le azioni Register e Thank You con la homepage, prova a separarle in un AccountController come il team MVC ha fatto nel progetto di esempio. Puoi utilizzare il routing per impostare l'Url in alto come vuoi per l'utente finale.

Come per le altre tue azioni, che ne dici di un ReportController? Inoltre, è possibile disporre di un AdministrationController la cui azione/vista Indice contiene collegamenti a varie azioni di amministrazione, comprese quelle sul ReportController.

Versione breve: Azioni di gruppo in un controller in base alla funzione, non nella navigazione del sito.

+0

Lo capisco, ma per quanto riguarda le visualizzazioni? Nello scenario che ho descritto, potrei desiderare che le azioni del controller per la sezione admin ereditino una pagina master separata rispetto a quelle della sezione utente. Non sembra essere un buon modo logico per isolare le viste in questo modo in base alla pagina principale che usano. – Chris

+0

azioni del controllore = viste, intendo – Chris

+0

Si potrebbe avere una pagina di amministrazione Admin nella cartella Views/Admin delle viste in Views/Report. Non vedo nulla di sbagliato nel farlo - stai parlando davvero di modelli di presentazione qui, niente di ciò che il controller dovrebbe sapere. – Troy

3

Solitamente metto il controller "Home" come prima cosa in un progetto e lo sostituisco con un controller "Pagina". Lo uso per tutto ciò che è "solo" una pagina. Cose come "FAQ", "Contattaci", ecc. Lo faccio almeno parzialmente perché l'approccio predefinito al controller Home richiede l'aggiunta di un nuovo metodo ogni volta che è necessaria anche una pagina statica di base.

In quel controller, ho solo un'azione: Display. Quell'azione dà a tutte quelle pagine lo stesso oggetto di contesto. In realtà, io memorizzo il contenuto per quelle pagine nel database con una "slug" di ricerca e lo lego ai modelli di NVelocity, ma anche i file HTML statici o NVelocity nei file potrebbero funzionare.

Qualsiasi altra cosa, come hanno detto gli altri, viene divisa in controller dalla "cosa" gestita. Quindi, un ReportController, User o AccountController, CartController, ecc. Quindi le azioni hanno molto più senso.

Quando parli di elencare gli utenti registrati, in realtà è un elenco di utenti, quindi dovrei avere un UserController e fare/User/Display/Registered/MostRecent o qualcosa di simile. Per la registrazione stessa,/Utente/Registro che invierà a/User/SaveRegistration che potrebbe, a sua volta, reindirizzare a/User/DisplayProfile/NewUserID o/Page/Display/Home da lì.

Problemi correlati