MVC Architecture - Quanti controller ho bisogno?

Per il tuo esempio creerei due controller:

• Controller delle sessioni per il login e il logout (crea e distruggi la sessione per il layout simile a REST)
• File Controller per tutto ciò che riguarda i file (index = search e create = upload)

In generale, un approccio RESTful in cui si pensa a tutto come una risorsa che può essere visualizzata, creata, modificata e distrutta offre una buona idea su come strutturare le cose. Come puoi vedere dai miei esempi, non rimango troppo vicino a ogni singolo verbo in REST.

Molto probabilmente avresti bisogno di più controller per ulteriori funzionalità. Ad esempio un controller utenti in cui gli utenti possono creare nuovi account. E oltre a questo avresti bisogno di un'interfaccia di amministrazione dove puoi modificare le risorse con privilegi più elevati. In tal caso è abbastanza comune avere quasi tutti i controller duplicati.

Una stima molto approssimativa per ottenere un'idea iniziale potrebbe essere un controller per ogni tabella nel database a cui gli utenti possono accedere. Ma questa è solo una misura molto approssimativa.

Dipende molto dall'app Web. Nel tuo esempio, uno è probabilmente sufficiente. Se dovessi implementare un'app di e-commerce in piena regola con spedizione, tasse, gestione delle scorte, prezzi differenziati, ecc., Potresti volerne un altro paio.

Se il tuo controller soffre di uno o più odori di codice (in particolare Large Class o God Object ) quindi sai che probabilmente hai superato il punto in cui ne avresti fatto uno solo.

In realtà dipende dalle esigenze dell'applicazione e dall'architettura dei moduli aziendali.

Una regola generale , il numero di controller richiesti dipende da un numero di moduli e sottomoduli nell'app Web.

Come complemento, sarebbe utile organizzare i controller in Aree . Il concetto di Aree è incorporato in ASP.NET MVC framework e semplifica l'organizzazione dei controller che servono un modulo.

Esistono numerose discussioni correlate:

• MVC Architecture
• Progettazione delle azioni del controller ASP.NET MVC
• mvc Controller e Visualizza l'organizzazione delle directory
• Che aspetto ha l'organizzazione della classe MVC per più viste e controller?

Mi piace il modo in cui Apple lo fa.

Every view is controlled by only one view controller. ~View Controller Programming Guide for iOS

L'idea è che dovresti essere in grado di scambiare facilmente le viste. IMO, avendo solo l'1% diController per% diView, rende più semplice l'operazione. Ma sono sicuro che potresti avere un controller con più viste e comunque progettarlo in modo da poter cambiare visualizzazione senza modificare la logica del programma.

Un esempio che mi piace è pensare a un termostato. Un termostato è un'ottima visuale per la visualizzazione del pattern MVC.

Su un termostato analogico più vecchio puoi immaginare cose come questa:

Visualizza : il lettore di temperatura, che visualizza la temperatura corrente.

Controller - La ghiera, dove cambi la temperatura

Modello : le parti all'interno invocate dal controller che causano il cambiamento della temperatura.

Dovresti sempre rispettare i progetti che consentono l'accoppiamento lento e i modelli limite e i relativi controllori associati a una singola attività , e dovresti utilizzare quanti più moduli / controller di cui hai bisogno . A seconda delle dimensioni della tua applicazione, potresti avere meno visualizzazioni rispetto a modelli e controller. Questo è normale con qualsiasi applicazione di grandi dimensioni. Una buona programmazione orientata agli oggetti è caratterizzata da accoppiamento lento, incapsulamento, ereditarietà e polimorfismo. Non tutte le lingue supportano il polimorfismo allo stesso grado (funzione, metodo, overloading / override dell'operatore).

Se vuoi avere una migliore comprensione dell'utilizzo dell'architettura MVC correttamente, consulta il GoF "Modelli di progettazione: elementi del software riutilizzabile ..." che utilizza C ++ e SmallTalk come codice di esempio. Questo libro non è l'alfa e l'omega, ma è certamente un inizio!

Buona fortuna!

Suppongo che il tuo esempio si evolverà in un sistema complesso.

applicazione:

Accesso utente:

• LoginController

La sua unica responsabilità è gestire gli accessi, reindirizzare o notificare all'utente l'esito.

Carica un file

• UploadController

Suppongo che tu voglia caricare qualsiasi tipo di file. Se in un secondo momento decidi di caricare MP3 e PDF, allora avrò un UploadController di base, MP3UploadController e PDFUploadController.

Cerca un file.

• SearchFileController

Questo sarebbe sufficiente per un requisito di base. È possibile avere più controller di ricerca in una data successiva a seconda della complessità della logica di ricerca. L'ultima cosa che vuoi avere è un singolo SearchController con 20 metodi di azione che eseguono ricerche diverse.

Esci.

- LogoutController .

Si potrebbe considerare questo un eccessivo, ma non penso che lo sia. Penso che sia pulito e ben separato.

Se dovessi esaminare questa struttura del progetto, saprei immediatamente cosa fa e come è strutturato. Per fare un ulteriore passo, metterei LoginController e LogoutController in un'area separata.

Ho sviluppato qualcosa di simile prima e ha funzionato molto bene.

La maggior parte del tuo codice si sarebbe verificata in un livello aziendale, giusto? Se questo è il caso, tutto ciò che stai facendo veramente nel controller è il ritorno dei dati alla vista.

Non sono sicuro se sono un fan della separazione dei controller in sottotipi. Mentre dovresti mantenere la separazione delle preoccupazioni, penso che i sottotipi stiano andando un po 'troppo oltre. Inoltre devi stare attento nei casi in cui oggetti pesanti sono inizializzati nel costruttore o in un controller. Ad esempio: nel tuo esempio vorresti un oggetto pesante, usato solo per il file di ricerca / caricamento da rilasciare quando l'utente si trova nella pagina di accesso.

È meglio avere un controller per unità logica, ad esempio AccountController (accesso, registrazione, disconnessione), FileController (ricerca, caricamento) e così via.

In generale si può dire che ogni MODELLO ha i propri CONTROLLER e VISTE dedicate. Dicendo generale intendo che questa è la migliore pratica.

Gli aspetti applicativi (come la gestione degli utenti) devono essere tradotti nel servizio applicativo e devono essere richiamati dal controllore stesso o avvolgere il controller (utilizzando attributi che rendono la funzionalità del controller "visibile" in base al ruolo utente richiesto, per esempio).

Ricorda che tutti i controller devono fondamentalmente gestire le operazioni CRUD sul modello e utilizzare viste diverse per filtri diversi.

A mio parere, uno dei principali vantaggi di MVC è che offre il modo migliore per legare modelli e viste.

Informazioni sull'esempio che hai aggiunto: Creerei 2 controller: uno per l'operazione di login di tutti gli utenti (registrazione, accesso, disconnessione ecc.) E il secondo per le operazioni sui file (caricamento e ricerca). si noti che il primo dovrebbe anche essere sottoposto a backup con alcuni aspetti relativi alla funzionalità di accesso e il secondo è un normale controller