Django vs. Model View Controller [chiuso]

110

Qualcuno può spiegarmi dove sono le differenze tra Django e il pattern Model View Controller?

Funzionalmente, cosa possiamo aspettarci da queste differenze, cioè cosa funziona in modo diverso confrontando Django, ad esempio, con Ruby on Rails?

django model-view-controller frameworks

— Leonardo
fonte

2

Quando dici "il" Model View Controller, intendi il pattern generale o un'implementazione specifica (come Ruby on Rails)?

— Paul D. Waite

33

Questa domanda non si qualifica come "non costruttiva" e ha una risposta diretta senza "dibattito, argomenti, sondaggi o discussioni estese". Perché chiuderla allora?

— utente

6

non costruttivo? Quindi i super mod colpiscono di nuovo.

— Amit Tripathi

4

Ad oggi, quasi 24.000 persone hanno trovato questa domanda costruttiva. Compreso me stesso.

— frozenjim

3

A partire dal 2017, questa domanda è ancora costruttiva

— Leonardo Pessoa

140

Secondo Django Book , Django segue il pattern MVC abbastanza da vicino da essere chiamato framework MVC.

Django è stato definito un framework MTV perché il controller è gestito dal framework stesso e la maggior parte dell'entusiasmo avviene in modelli, modelli e visualizzazioni.

Puoi leggere di più su MTV / MVC qui:

Il pattern di sviluppo MTV (o MVC)

Se hai familiarità con altri framework di sviluppo Web MVC, come Ruby on Rails, potresti considerare le viste Django come controller e i modelli Django come visualizzazioni .

Questa è una sfortunata confusione causata da diverse interpretazioni di MVC.

Nell'interpretazione di Django di MVC, la vista descrive i dati che vengono presentati all'utente; non è necessariamente solo come appaiono i dati, ma quali dati vengono presentati.

Al contrario, Ruby on Rails e framework simili suggeriscono che il compito del controller include decidere quali dati vengono presentati all'utente, mentre la visualizzazione è strettamente come appaiono i dati, non quali dati vengono presentati.

— Paolo Moretti
fonte

6

Grazie per la magnifica risposta. Venendo da Rails a Django, questo risponde a una delle cose che ho trovato più frustrante: perché django mette il codice del controller in un file chiamato views.py !?

— dgmdan

@dgmdan È solo una convenzione predefinita, puoi scegliere il nome che ti piace. Ma sono d'accordo, sembra strano :)

— Paolo Moretti

1

Preferirei lasciare views.py come livello di visualizzazione e creare un set di classi controller in un pacchetto controller per evitare la confusione di Django.

— stanleyxu2005

5

@dgmda: perché il concetto di "controller" è un termine improprio nelle webapp. MVC è un framework basato su eventi che non si adatta solo al modello REQUEST / RESPONSE senza stato di HTTP. Non dovrebbe essere chiamato MVC in primo luogo. Quasi tutte le webapp non sono MVC, ma utilizzano un modello e una funzione o una classe solitamente denominata View. La vista a sua volta può delegare il rendering HTML a un modello, ma non è necessario. Quindi non c'è un controller, in realtà.

— Lennart Regebro

2

Sostengo il concetto di Lennart Regebro che un modello senza stato come HTTP non dovrebbe avere un controller e un modello MVC per le webapp crea solo una grande confusione

— Hussam

23

La stessa FAQ di Django è un buon punto di partenza:

https://docs.djangoproject.com/en/dev/faq/general/#django-appears-to-be-a-mvc-framework-but-you-call-the-controller-the-view-and-the -view-the-modello-how-come-si-t-use-le-sTANDARD-nomi-don

Nella nostra interpretazione di MVC, la "vista" descrive i dati che vengono presentati all'utente. Non è necessariamente come appaiono i dati, ma quali dati vengono presentati. La vista descrive quali dati vedi, non come li vedi. È una sottile distinzione.

...

Inoltre, è sensato separare il contenuto dalla presentazione, che è qui che entrano in gioco i modelli. In Django, una "vista" descrive quali dati vengono presentati, ma una vista normalmente delega a un modello, che descrive come vengono presentati i dati.

Dove si inserisce il "controllore", allora? Nel caso di Django, è probabilmente il framework stesso: il meccanismo che invia una richiesta alla vista appropriata, in base alla configurazione dell'URL di Django.

Se sei affamato di acronimi, potresti dire che Django è un framework "MTV", ovvero "modello", "modello" e "visualizzazione". Quella rottura ha molto più senso.

Tieni presente che "Model View Controller" è solo un modello, ovvero un tentativo di descrivere un'architettura comune. Quindi una domanda migliore potrebbe essere "Quanto bene Django si adatta al pattern Model View Controller?"

— Paul D. Waite
fonte

3

Questa è forse la risposta più diretta.

— utente

11

Quando si codifica, senza pensare ai nomi dei pezzi del framework, non ci sono differenze sospettose tra, ad esempio RoR. Ma dipende dall'uso che ne fai models, dato che su Django contengono facilmente una logica che su altri framework rimarrebbe a livello di controller.

L' viewon Django tende ad essere una serie di query per i dati recupero, e passarle al modello.

— inigomedina
fonte

10

A viewsin Django è qualcosa come a controllerin MVC e a templatein Django è più probabile aviews

— Roel

7

In mvt, una richiesta a un URL viene inviata a una vista. Questa vista richiama il modello, esegue manipolazioni e prepara i dati per l'output. I dati vengono passati a un modello che viene renderizzato ed emesso come risposta. idealmente nei framework web, il controller è nascosto alla vista.

Qui è dove la differenza è da MVC: in mvc, l'utente interagisce con la gui, il controller gestisce la richiesta e notifica il modello e la vista interroga il modello per mostrare il risultato all'utente.

— Samuele Mattiuzzo
fonte