Controlador de vista de modelo vs.Django [cerrado]

110

¿Alguien puede explicarme dónde están las diferencias entre Django y el patrón Model View Controller?

Funcionalmente, ¿qué podemos esperar de esas diferencias, es decir, qué funciona de manera diferente comparando Django con, por ejemplo, Ruby on Rails?

django model-view-controller frameworks Leonardo
fuente
2
Cuando dice “el” controlador de vista de modelo, ¿se refiere al patrón general oa una implementación específica (como Ruby on Rails)?
Paul D. Waite
33
Esta pregunta no califica como "no constructiva" y tiene una respuesta directa sin "debate, argumentos, encuestas o discusión extensa". ¿Por qué cerrarlo entonces?
usuario
6
no constructivo? Así que los super mods atacan de nuevo.
Amit Tripathi
4
A la fecha, casi 24.000 personas encontraron constructiva esta pregunta. Incluyendome.
Frozenjim
3
A partir de 2017, esta pregunta sigue siendo constructiva
Leonardo Pessoa

Respuestas:

140

Según el Libro de Django , Django sigue el patrón MVC lo suficientemente de cerca como para ser llamado un marco MVC.

Se ha hecho referencia a Django como un marco MTV porque el controlador lo maneja el marco mismo y la mayor parte de la emoción ocurre en los modelos, plantillas y vistas.

Puede leer más sobre MTV / MVC aquí:

El patrón de desarrollo de MTV (o MVC)

Si está familiarizado con otros marcos de desarrollo web MVC, como Ruby on Rails, puede considerar que las vistas de Django son los controladores y las plantillas de Django las vistas .

Esta es una desafortunada confusión provocada por diferentes interpretaciones de MVC.

En la interpretación de Django de MVC, la vista describe los datos que se presentan al usuario; no es necesariamente solo cómo se ven los datos, sino qué datos se presentan.

Por el contrario, Ruby on Rails y marcos similares sugieren que el trabajo del controlador incluye decidir qué datos se presentan al usuario, mientras que la vista es estrictamente cómo se ven los datos, no qué datos se presentan.

Paolo Moretti
fuente
6
Gracias por la gran respuesta. Viniendo de Rails a Django, esto responde a una de las cosas que encontré más frustrantes: ¿por qué django coloca el código del controlador en un archivo llamado views.py?
dgmdan
@dgmdan Es solo una convención predeterminada, puede elegir el nombre que desee. Pero estoy de acuerdo, parece raro :)
Paolo Moretti
1
Prefiero dejar views.py como una capa de vista y crear un conjunto de clases de controlador en un paquete de controlador para evitar la confusión de Django.
stanleyxu2005
5
@dgmda: porque el concepto de "controlador" es un nombre inapropiado en las aplicaciones web. MVC es un marco impulsado por eventos que no se ajusta solo al modelo sin estado REQUEST / RESPONSE de HTTP. No debería llamarse MVC en primer lugar. Casi todas las aplicaciones web no son MVC, pero usan un modelo y una función o clase que generalmente se llama Vista. La Vista, a su vez, puede delegar la representación HTML a una Plantilla, pero no es necesario. Entonces, en realidad, no hay un controlador.
Lennart Regebro
2
Apoyo el concepto de Lennart Regebro de que un modelo sin estado como HTTP no debería tener un controlador y un modelo MVC para aplicaciones web solo genera una gran confusión
Hussam
23

Las preguntas frecuentes de Django en sí mismas son un buen lugar para comenzar:

En nuestra interpretación de MVC, la "vista" describe los datos que se presentan al usuario. No se trata necesariamente de cómo se ven los datos, sino de qué datos se presentan. La vista describe qué datos ve, no cómo los ve. Es una distinción sutil.

...

Además, es sensato separar el contenido de la presentación, que es donde entran las plantillas. En Django, una "vista" describe qué datos se presentan, pero una vista normalmente delega a una plantilla, que describe cómo se presentan los datos.

Entonces, ¿dónde encaja el "controlador"? En el caso de Django, probablemente sea el marco en sí: la maquinaria que envía una solicitud a la vista adecuada, de acuerdo con la configuración de la URL de Django.

Si tiene hambre de acrónimos, podría decir que Django es un marco "MTV", es decir, "modelo", "plantilla" y "vista". Ese desglose tiene mucho más sentido.

Tenga en cuenta que “Model View Controller” es solo un patrón, es decir, un intento de describir una arquitectura común. Entonces, una mejor pregunta podría ser "¿Qué tan bien se ajusta Django al patrón Model View Controller?"

Paul D. Waite
fuente
3
Ésta es quizás la respuesta más directa.
usuario
11

Cuando codifica, sin pensar en los nombres de las piezas del marco, no hay diferencias sustanciales entre, por ejemplo, RoR. Pero depende del uso que le des models, ya que en Django fácilmente contienen alguna lógica que en otros frameworks se quedaría a nivel de controlador.

El viewen Django tiende a ser un conjunto de consultas para obtener datos y pasarlos a la plantilla.

inigomedina
fuente
10
A viewsen Django es algo así como a controlleren MVC y a templateen Django es más probable aviews
Roel
7

En mvt, una solicitud a una URL se envía a una vista. Esta vista llama al modelo, realiza manipulaciones y prepara los datos para su salida. Los datos se pasan a una plantilla que se procesa y se emite como respuesta. idealmente en frameworks web, el controlador está oculto a la vista.

Aquí es donde está la diferencia con MVC: en mvc, el usuario interactúa con la interfaz gráfica de usuario, el controlador maneja la solicitud y notifica al modelo y la vista consulta el modelo para mostrar el resultado al usuario.

Samuele Mattiuzzo
fuente