Il framework MVC sembra suggerire la creazione di centinaia di pagine .aspx o .cshtml. Come posso evitare questo?

Naviga le tue risposte
6

Quindi, stavo giocando con MVC3. Correggimi se sbaglio, ma sulla base di tutti gli esempi che ho visto, è consigliabile che tu abbia praticamente una pagina per ogni modello e Azione dal Controller. Ad esempio, crea un portale di gestione piuttosto semplice per il database aspnetdb.

Modelli

UserModel
Rolemodel

Azioni

CreateUserAction
DeleteUserAction
ChangeUserAction
CreateRoleAction
DeleteRoleAction
UpdateRoleAction
AssignUserToRoleAction
AssignUsersToRoleAction
AssignUserToRoleAction
AssignUsersToRolesAction
DeleteUsersFromRoleAction
ecc ...

Pagine

CreateUser.aspx o .cshtml
DeleteUser.aspx o .cshtml
ChangeUser.aspx o .cshtml

CreateRole.aspx o .cshtml DeleteRole.aspx o .cshtml
UpdateRole.aspx o .cshtml
AssignUserToRole.aspx o .cshtml
AssignUsersToRole.aspx o .cshtml
AssignUserToRole.aspx o .cshtml
AssignUsersToRoles.aspx o .cshtml
DeleteUsersFromRole.aspx o .cshtml

    
posta MVCylon 01.06.2011 - 19:18
fonte

1 risposta

9

È vicino alla verità. Le visualizzazioni complete e parziali aumentano rapidamente di numeri mentre procedi.

Questo è comunque molto più preferibile ad avere un'unica pagina WebForms che si occupa di tutto. Con il tempo si trasforma tipicamente in un gigantesco blurb ingestibile che ti costringe a riprendere la cosa e probabilmente a rifare l'intero lavoro. Sai, siamo stati tutti lì.

Qui hai un'opzione per dividere il tuo livello di presentazione in piccoli pezzi gestibili. Puoi svilupparli separatamente, riutilizzarli. È anche possibile impostare OutputCache per azione che offre una grande flessibilità. Personalmente lo trovo fantastico.

In breve: è una buona cosa!

    
risposta data 01.06.2011 - 19:35
fonte

Leggi altre domande sui tag

Che cosa significa per software, librerie e lingue essere asincroni? Dove memorizzi le tue build?