Quando utilizzare i controller in mvc

1

Sto studiando mvc5 in asp.net e mi chiedo se c'è una regola generale quando usare un controller. Se ho un oggetto business come Employee creerò un controller chiamato Employeecontroller? Ma perché e quali sono i vantaggi di avere un controller in primo luogo?

Voglio capire quando creare un controller e quali sono i vantaggi. Ho cercato nei tutorial di mvc5 ma non dicono quando creare i controller.

    
posta Layior 11.02.2015 - 20:13
fonte

4 risposte

1

Si utilizza un controller quando è necessario accedere a una risorsa esternamente. Quindi se stai costruendo un'interfaccia per modificare le informazioni dei dipendenti, allora hai bisogno di un controller lì.

Solo perché hai una risorsa, però, non significa che hai bisogno di un controller per questo. Supponiamo che tu abbia una classe / modello di ubicazione che si riferisce agli indirizzi. Forse un dipendente ha molte sedi, ma quelle posizioni sono tutte manipolate attraverso le visualizzazioni dei dipendenti. Bene, in questo caso, il dipendente è ancora la risorsa a cui si accede in modo da non aver bisogno di un LocationController. Avrai bisogno di una vista per rappresentare quel modello probabilmente, ma ciò avverrebbe con viste parziali.

I controllori dovrebbero essere utilizzati per governare le azioni necessarie all'interno di un'applicazione per controllare l'accesso alle risorse. Il trucco è davvero definire: cos'è una risorsa e cos'è semplicemente una classe di supporto?

    
risposta data 11.02.2015 - 20:23
fonte
0

Un controller è il mediatore tra il modello e la vista. In sostanza, il controllore legge l'input dell'utente dalla vista e aggiorna il modello in base alle modifiche.

Senza un controller, la vista sarà accoppiata troppo strettamente con il modello di dati. Se dovessi cambiare una piccola cosa nel modello, potrebbe rovinare completamente la vista. Considerando che se si dispone di un controller, una modifica al modello non fa nulla finché non lo si collega al controller e alla vista.

L'intero punto è la separazione delle preoccupazioni. È possibile pensare mentalmente alla vista come all'interfaccia utente, al controller come al luogo in cui si posizionano le regole aziendali, ecc. E al modello come ai dati con cui si desidera interfacciare. Senza una tale separazione, avrai la logica del controller sia nella vista che nel modello, e il codice diventerà un inferno da mantenere e migliorare.

    
risposta data 11.02.2015 - 20:21
fonte
0

L'intero punto di MVC è il disaccoppiamento degli strati l'uno dall'altro. Il lavoro dell'interfaccia utente può essere svolto indipendentemente dalle regole aziendali. Le regole aziendali possono essere elaborate indipendentemente dall'interfaccia utente o dall'accesso ai dati. E il Modello può estrarre tutti i dati che desidera indipendentemente dalle regole di Business.

Si noti che l'interfaccia utente e il modello non dovrebbero mai conoscersi l'un l'altro.

La "logica aziendale" relativa a Employee è ciò che dovrebbe andare in EmployeeController . E quando crei un controller? Quando si dispone della logica aziendale per acquisire informazioni su un oggetto di sistema. Bene, che cos'è la logica aziendale? Essenzialmente sono le regole sull'agire su Employee o altri oggetti che non sono artefatti dell'interfaccia utente o artefatti del livello di persistenza.

Il vantaggio di questo è che ogni livello è più facile da testare poiché forniscono, in sostanza, un contratto agli altri livelli. Un altro vantaggio è che più UI possono utilizzare lo stesso controller senza richiedere una riscrittura (o copia e incolla) del controller esistente.

    
risposta data 11.02.2015 - 20:21
fonte
0

È davvero una questione di opinione. Nel pattern MVC standard per le applicazioni Web, l'utente esegue un controller per azione, ma come molte altre implementazioni moderne del pattern, Asp.net MVC consente di avere più azioni in una singola classe di controller. Raggrupparli per entità che influenzano è un'opzione, così come avere una classe per ogni azione, e sono sicuro che ci sono altri schemi che potresti usare anche tu. Sospetto che l'unica cosa importante sia scegliere una strategia ed essere coerenti, altrimenti non riuscirai a trovare le implementazioni del controller.

    
risposta data 11.02.2015 - 20:26
fonte

Leggi altre domande sui tag