Django vs. Model View Controller [fechado]

110

Alguém pode me explicar onde estão as diferenças entre o Django e o padrão Model View Controller?

Funcionalmente, o que podemos esperar dessas diferenças - ou seja, o que funciona de forma diferente comparando Django a, por exemplo, Ruby on Rails?

django model-view-controller frameworks

— Leonardo
fonte

2

Quando você diz “o” Model View Controller, você quer dizer o padrão geral ou uma implementação específica (como Ruby on Rails)?

— Paul D. Waite

33

Esta questão não se qualifica como 'não construtiva' e tem uma resposta direta sem "debate, argumentos, votação ou discussão extensa". Por que fechá-lo então?

— usuário

6

não construtivo? ASSIM, os supermods atacam novamente.

— Amit Tripathi

4

Até hoje, quase 24.000 pessoas acharam esta pergunta construtiva. Incluindo me a mim.

— frozenjim de

3

A partir de 2017, esta questão ainda é construtiva

— Leonardo Pessoa

140

De acordo com o Django Book , o Django segue o padrão MVC próximo o suficiente para ser chamado de framework MVC.

Django tem sido referido como um framework MTV porque o controlador é manipulado pelo próprio framework e a maior parte do entusiasmo acontece em modelos, templates e visualizações.

Você pode ler mais sobre MTV / MVC aqui:

O padrão de desenvolvimento MTV (ou MVC)

Se você está familiarizado com outras estruturas de desenvolvimento da Web MVC, como Ruby on Rails, você pode considerar as visualizações do Django como os controladores e os modelos do Django como as visualizações .

Esta é uma confusão infeliz ocasionada por diferentes interpretações do MVC.

Na interpretação do Django de MVC, a visão descreve os dados que são apresentados ao usuário; não é necessariamente apenas a aparência dos dados, mas quais dados são apresentados.

Em contraste, Ruby on Rails e estruturas semelhantes sugerem que o trabalho do controlador inclui decidir quais dados são apresentados ao usuário, enquanto a visualização é estritamente como os dados se parecem, não quais dados são apresentados.

— Paolo Moretti
fonte

6

Obrigado pela ótima resposta. Vindo de Rails para Django, isso responde a uma das coisas que achei mais frustrantes: por que o django coloca o código do controlador em um arquivo chamado views.py !?

— dgmdan

@dgmdan É apenas uma convenção padrão, você pode escolher o nome que quiser. Mas eu concordo, parece estranho :)

— Paolo Moretti

1

Eu prefiro deixar views.py como uma camada de visão e criar um conjunto de classes de controlador em um pacote de controlador para evitar a confusão do Django.

— stanleyxu2005

5

@dgmda: Porque o conceito de "controlador" é um nome impróprio em aplicativos da web. MVC é uma estrutura orientada a eventos que não se encaixa apenas no modelo REQUEST / RESPONSE sem estado de HTTP. Não deveria ser chamado MVC em primeiro lugar. Quase todos os webapps não são MVC, mas usam um modelo e uma função ou classe geralmente chamada de View. A View, por sua vez, pode delegar a renderização HTML a um Template, mas não é necessário. Portanto, não há um controlador, na verdade.

— Lennart Regebro

2

Eu apoio o conceito de Lennart Regebro de que um modelo sem estado como o HTTP não deveria ter um controlador e um modelo MVC para webapps só traz grande confusão

— Hussam

23

O próprio Django FAQ é um bom lugar para começar:

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-template-how-come-you-don-t-use-the-standard-names

Em nossa interpretação do MVC, a “visão” descreve os dados que são apresentados ao usuário. Não é necessariamente a aparência dos dados, mas quais dados são apresentados. A visualização descreve quais dados você vê, não como você os vê. É uma distinção sutil.

...

Além disso, é sensato separar o conteúdo da apresentação - que é onde os modelos entram. No Django, uma “visão” descreve quais dados são apresentados, mas uma visão normalmente delega a um modelo, que descreve como os dados são apresentados.

Onde o “controlador” se encaixa, então? No caso do Django, é provavelmente o próprio framework: a máquina que envia uma solicitação para a visualização apropriada, de acordo com a configuração de URL do Django.

Se você está ávido por siglas, pode dizer que Django é uma estrutura “MTV” - ou seja, “modelo”, “modelo” e “visualização”. Essa divisão faz muito mais sentido.

Tenha em mente que “Model View Controller” é apenas um padrão, ou seja, uma tentativa de descrever uma arquitetura comum. Portanto, uma pergunta melhor pode ser “Quão bem o Django se ajusta ao padrão Model View Controller?

— Paul D. Waite
fonte

3

Esta é talvez a resposta mais direta.

— usuário

11

Quando você codifica, sem pensar nos nomes das peças do framework, não há diferenças sustentáveis entre, por exemplo, RoR. Mas depende do uso que você dá models, já que no Django eles facilmente contêm alguma lógica que em outros frameworks ficaria no nível do controlador.

O viewno Django tende a ser um conjunto de consultas para buscar dados e passá-los para o modelo.

— inigomedina
fonte

10

Um viewsem Django é algo como um controllerem MVC e um templateem Django é mais provavelmente umviews

— Roel

7

No mvt, uma solicitação de URL é enviada para uma visualização. Esta visualização chama o modelo, executa manipulações e prepara os dados para a saída. Os dados são passados para um Template que é renderizado e emitido como uma resposta. idealmente em estruturas da web, o controlador fica oculto.

É aqui que está a diferença do MVC: no mvc, o usuário interage com a gui, o controlador lida com a solicitação e notifica o modelo e a visualização consulta o modelo para exibir o resultado ao usuário.

— Samuele Mattiuzzo
fonte