Perché tutti mettono i controller in una cartella e le viste in un'altra?

Mi piacerebbe dire che è programmazione culto cargo , ma ci sono motivi tecnici per questa struttura. Asp.Net MVC ha preso una convenzione sull'approccio alla configurazione per quasi tutto. Per impostazione predefinita, il motore di visualizzazione Razor cerca la directory Views per risolvere la vista da restituire dal controller. Esistono tuttavia alcune hack per ottenere una diversa struttura del progetto e Microsoft fornisce anche una funzionalità MVC chiamata Aree per permetterci di creare una struttura di progetto più sana. Puoi anche implementare il tuo motore di visualizzazione per specificare dove cercare le viste.

Perché dico che è la programmazione settoriale del carico e che tu hai ragione su questo? Uncle Bob mi ha convinto che la struttura della directory del progetto non dovrebbe dirmi che si tratta di un'applicazione MVC. Dovrebbe dirmi che si tratta di un fronte negozio, o un sistema di richiesta di tempo libero, o qualsiasi altra cosa. La struttura e l'architettura di alto livello dovrebbero dirci su cosa questa cosa è, non come è stata implementata.

In breve, credo che tu abbia ragione su questo, ma qualsiasi altra struttura di directory semplicemente starebbe combattendo contro il framework e credimi quando dico che non vuoi provare a fare il framework Asp.Net MVC qualcosa che non è stato progettato per fare. È un peccato che non sia più configurabile in realtà.

Per affrontare rapidamente i problemi di architettura, credo ancora che i modelli di business (business, non view) e DAL dovrebbero vivere in un progetto / libreria separato che viene chiamato dall'app MVC.

È solo che il controller è davvero molto unito alla vista e probabilmente sarà modificato insieme. Siamo tutti saggiosi di ricordare la differenza tra l'accoppiamento tramite dipendenza e l'accoppiamento logico. Solo perché il codice ha avuto le sue dipendenze disaccoppiate non lo rende meno logicamente accoppiato.

Qualunque sia la ragione, questa è una cattiva pratica. È molto anti-OO perché i pacchetti o le cartelle (qualunque cosa tu voglia chiamarli), dovrebbero avere interdipendenze deboli. Le classi (o file) al loro interno dovrebbero avere forti interdipendenze.

Lanciando tutte le viste in una cartella e tutti i controller in un'altra cartella si creano due pacchetti con un accoppiamento molto stretto. Questo va contro il principio di avere deboli interpack dipendenze.

Una vista e un controller sono due metà di un intero e dovrebbero appartenere l'uno all'altro. Non avresti un sorteggio per i calzini sul lato sinistro e un altro per i calzini sul lato destro.

Per rispondere al tuo "Perché tutti ...?" domanda: Ecco alcuni potenziali motivi, anche se non sono del tutto sicuro quale combinazione di essi sia una vera causa, poiché in realtà è una domanda soggettiva

• Per replicare l'architettura logica (modello, vista, controller) con una cartella e una struttura dello spazio dei nomi corrispondenti

• Fuori dalla convention e amp; convenienza nel seguire il modello di progetto MVC ASP.net

• Per raggruppare per spazio dei nomi, poiché la cartella Controllers/ porterà a uno spazio dei nomi .Controllers

• Potrebbe abilitare alcuni scenari in DI / IoC dove le classi controller vengono solo interrogate / scansionate da uno spazio dei nomi che contiene / termina-con 'Controllers' (potrebbe essere sbagliato)

• Per consentire ai modelli T4 di scansionare e modelli di scaffold & controller per generare viste

Puoi sempre creare e seguire la tua convention se ha senso per il tuo progetto, nessuno può fermarti o fermarti. Ma tieni presente che se lavori in un grande progetto e / o in una grande squadra, allora la convenzione di default che è nota a tutti potrebbe essere una scelta migliore (non necessariamente quella giusta, però!)

Se la tua convenzione è più facile da seguire e non ostacola la produttività, allora fallo con tutti i mezzi! e forse anche scrivere su di esso un post sul blog o due per socializzare con la comunità degli sviluppatori e ottenere un feedback

Non necessariamente tutti lo fanno. Ad esempio, il framework Django di python ha il concetto di un'app, in cui i sottomoduli della tua applicazione vivono nelle proprie directory con i propri modelli e viste e modelli (le viste sono ciò che Django chiama essenzialmente i controller). Mi piace preferire questo modo di fare le cose perché ciò significa che posso facilmente impacchettare una "app" e riutilizzarla attraverso i progetti semplicemente includendola nell'elenco delle app nelle impostazioni dei miei progetti. È anche più facile scoprire dove sono le diverse parti. Se guardo il file urls.py e vedo qualcosa come url(r'^users/', include('my_site.users.urls')) , so che il modulo my_site.users contiene tutto il codice che gestisce gli utenti. So di guardare i moduli my_site.users.views e my_site.users.models quando voglio vedere come gli utenti vengono creati e autenticati. So che tutti i miei percorsi sono definiti in my_site.users.url .

Anche se è abbastanza generico, probabilmente posso usare quel modulo in altri siti semplicemente cambiando la configurazione o impacchettandolo come libreria e pubblicandolo come OSS.

Ricorda che è Microsoft modo consigliato per mantenere i controller e le viste in una cartella diversa, quindi molti seguiranno la struttura consigliata,

1. Un motivo potrebbe essere che i controllori non abbiano sempre una relazione uno a uno con le viste, specialmente le viste parziali possono essere condivise tra i controllori.
2. Un altro motivo potrebbe essere quando il tuo progetto cresce, potresti voler estrarre controller e unit test in un altro progetto, ma è piuttosto difficile fare lo stesso per le viste e le viste / js / css appartengono come fanno riferimento l'un l'altro.

Avendo detto che ci sono molti post su come farlo a modo tuo, come questo .

Un motivo per mantenere viste e controllori in directory separate è quando gli sviluppatori front-end e back-end lavorano su un progetto. Puoi impedire agli sviluppatori front-end di accedere al codice di back-end (ad esempio, per agevolare la conformità PCI, limitando chi ha accesso al codice sensibile).

Un altro motivo è rendere più semplice avere "temi" e disattivare tutti dei modelli apportando una piccola modifica al percorso della vista.

Una terza ragione è avere un modello di directory semplice quando si specificano le viste nel framework MVC. È più semplice specificare la sottodirectory e il file piuttosto che un grande percorso lungo per ciascuna vista.

L'unico "accoppiamento stretto" dovrebbe essere:

1. Variabili inviate nella vista dal controller.
2. Campi modulo o azioni nella vista, inviati al controller.

Uso un controller generico e cerco di mantenere i nomi delle variabili nella vista generica, in modo che molte viste possano utilizzare lo stesso controller e molti controller possono utilizzare la stessa vista. Per questo motivo preferisco mantenere le opinioni completamente separate. Il modello è dove puoi differenziare ogni "cosa" nella tua applicazione - possono essere oggetti con un elenco di proprietà e metodi per accedere / modificare queste proprietà.

Per un codice strettamente accoppiato, un approccio che potrebbe funzionare per te è mantenere tutti i file che fanno parte di un pacchetto o di un "modulo" insieme in una directory con nomi. Quindi puoi usare uno script per copiare o "compilare" i tuoi modelli grezzi nella directory principale "views". Per esempio:

    lib/my-namespace/my-package/
        -> controllers/
        -> models/
        -> views/
            -> theme/
               -> template-name1
    app/compiled_views/theme/
        -> url/path/template-name1

Sfortunatamente, se vuoi cambiare la struttura di un tema esistente, c'è più intreccio dentro e fuori dalle directory dei pacchetti per aggiornare le viste.

Considera che le viste sono solo un modo per formattare i dati, che si tratti di json, xml, csv o html. Ciò è particolarmente utile se vuoi che la tua applicazione funzioni anche come API. Prova a separare la vista dai dati, utilizzando nomi di variabili generiche, in modo da poter utilizzare lo stesso modello per molti controller o modelli (o utilizzare include per ridurre al minimo la quantità di codice che è necessario mantenere).

Per la cronologia

Why do I say that it's cargo cult programming and that you're correct about this? Uncle Bob convinced me that the project's directory structure shouldn't tell me that it's an MVC application. It should tell me that it's a store front, or a time off request system, or whatever. The high level structure and architecture should tell us about what this thing is, not how it was implemented.

Domanda: chi ha accesso al codice ?. I programmatori. Gli utenti finali si preoccupano del codice ?. No. E, cosa fa un programmatore, codice. O più specificamente, classi basate su tipi (controllori, servizi, modelli e così via). Quindi ha senso ed è facile eseguire il debug di un codice, se sei in grado di trovare un codice basato sul tipo di codice, anziché nel comportamento del codice. Inoltre, diciamo un progetto di squadra, uno è responsabile del controller, un altro del modello, un altro del dao e un altro della vista. È facile separare il progetto in parti. Un buon codice è un codice facile da eseguire il debug, non un codice zucchero di sintassi. Zio Bob ha torto di nuovo.

Cercare di imitare il comportamento del progetto (il fronte di un negozio) è un culto del carico.