Django против контроллера представления модели [закрыто]


110

Может ли кто-нибудь объяснить мне, в чем разница между Django и шаблоном Model View Controller?

С функциональной точки зрения, что мы можем ожидать от этих различий - то есть, что работает по-разному при сравнении Django, например, с Ruby on Rails?


2
Когда вы говорите «Контроллер представления модели», вы имеете в виду общий шаблон или конкретную реализацию (например, Ruby on Rails)?
Пол Д. Уэйт

33
Этот вопрос не квалифицируется как «неконструктивный» и имеет прямой ответ без «дебатов, аргументов, опросов или расширенного обсуждения». Зачем тогда закрывать?
пользователь

6
не конструктивно? ТАК супер моды снова бьют.
Амит Трипати,

4
На сегодняшний день почти 24 тысячи человек сочли этот вопрос конструктивным. В том числе и я.
Frozenjim

3
По состоянию на 2017 год этот вопрос все еще является конструктивным
Леонардо Песоа

Ответы:


140

Согласно книге Django , Django следует шаблону MVC достаточно близко, чтобы его можно было назвать фреймворком MVC.

Django называют фреймворком MTV, потому что контроллер обрабатывается самим фреймворком, и большая часть ажиотажа возникает в моделях, шаблонах и представлениях.

Вы можете узнать больше о MTV / MVC здесь:

Шаблон развития MTV (или MVC)

Если вы знакомы с другими средами веб-разработки MVC, такими как Ruby on Rails, вы можете рассматривать представления Django как контроллеры, а шаблоны Django - как представления .

Это досадная путаница, вызванная разными интерпретациями MVC.

В интерпретации MVC Django представление описывает данные, которые представляются пользователю; Дело не только в том, как данные выглядят, а в том, какие данные представлены.

Напротив, Ruby on Rails и подобные фреймворки предполагают, что задача контроллера включает в себя решение, какие данные будут представлены пользователю, тогда как представление строго соответствует тому, как данные выглядят, а не какие данные представлены.


6
Спасибо за отличный ответ. Переход от Rails к Django, это ответ на один из вопросов, который меня больше всего расстраивает: почему django помещает код контроллера в файл с именем views.py !?
dgmdan

@dgmdan Это просто соглашение по умолчанию, вы можете выбрать любое имя. Но я согласен, это кажется странным :)
Паоло Моретти

1
Я бы предпочел оставить views.py в качестве уровня представления и создать набор классов контроллеров в пакете контроллера, чтобы избежать путаницы с Django.
stanleyxu2005

5
@dgmda: Потому что понятие «контроллер» неправильно употребляется в веб-приложениях. MVC - это среда, управляемая событиями, которая не подходит только для HTTP-модели REQUEST / RESPONSE без сохранения состояния. Во-первых, его не следует называть MVC. Почти все веб-приложения не являются MVC, но используют модель и функцию или класс, обычно называемые View. Представление, в свою очередь, может делегировать отрисовку HTML шаблону, но в этом нет необходимости. Так что на самом деле контроллера нет.
Леннарт Регебро

2
Я поддерживаю концепцию Леннарта Регебро о том, что модель без сохранения состояния, такая как HTTP, не должна иметь контроллера, а модель MVC для веб-приложений просто вызывает серьезную путаницу
Хусам

23

Сама по себе Django FAQ - хорошее место для начала:

В нашей интерпретации MVC «представление» описывает данные, которые представляются пользователю. Дело не в том, как выглядят данные, а в том, какие данные представлены. Представление описывает, какие данные вы видите, а не то, как вы их видите. Это тонкое различие.

...

Кроме того, разумно отделить контент от представления - здесь и появляются шаблоны. В Django «представление» описывает, какие данные представлены, но представление обычно делегируется шаблону, который описывает, как данные представлены.

Где же тогда «контроллер»? В случае Django, вероятно, это сама структура: машина, которая отправляет запрос в соответствующее представление в соответствии с конфигурацией URL-адреса Django.

Если вам не хватает аббревиатур, можно сказать, что Django - это фреймворк MTV, то есть «модель», «шаблон» и «представление». В этой разбивке гораздо больше смысла.

Помните, что «Контроллер представления модели» - это просто шаблон, то есть попытка описать общую архитектуру. Так что лучший вопрос может быть: «Насколько хорошо Django соответствует шаблону Model View Controller?»


3
Это, пожалуй, самый прямой ответ.
пользователь

11

Когда вы пишете код, не думая о названиях частей фреймворка, между ними нет никаких подозрительных различий, например RoR. Но это зависит от вашего использования models, поскольку в Django они легко содержат некоторую логику, которая в других фреймворках останется на уровне контроллера.

В viewDjango обычно представляет собой набор запросов для получения данных и передачи их в шаблон.


10
A viewsв Django - это что-то вроде controllerMVC, а templateв Django, скорее, aviews
Роэл

7

В mvt запрос к URL-адресу отправляется в представление. Это представление вызывает модель, выполняет манипуляции и подготавливает данные для вывода. Данные передаются в шаблон, который отображается в качестве ответа. в идеале в веб-фреймворках контроллер скрыт от глаз.

В этом отличие от MVC: в mvc пользователь взаимодействует с графическим интерфейсом пользователя, контроллер обрабатывает запрос и уведомляет модель, а представление запрашивает модель, чтобы отобразить результат пользователю.

Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.