Контролер перегляду Django vs. Model [закрито]

110

Наразі це запитання не підходить для нашого формату запитань. Ми очікуємо, що відповіді будуть підкріплені фактами, посиланнями або експертними знаннями, але це питання, ймовірно, вимагатиме дискусій, аргументів, опитувань чи розширеної дискусії. Якщо ви вважаєте, що це питання можна вдосконалити та, можливо, знову відкрити, відвідайте довідковий центр для ознайомлення .

Закрито 7 років тому .

Чи може хтось пояснити мені, де різняться між Django та моделлю контролера перегляду моделі?

Функціонально, чого ми можемо очікувати від цих відмінностей - тобто те, що працює по-різному порівняно з Django, наприклад, Ruby on Rails?

django model-view-controller frameworks

— Леонардо
джерело

2

Коли ви говорите "контролер перегляду моделі", ви маєте на увазі загальну схему чи конкретну реалізацію (наприклад, Ruby on Rails)?

— Пол Д. Уейт

33

Це питання не кваліфікується як "неконструктивне" і має пряму відповідь без "дискусій, аргументів, опитування чи розширеної дискусії". Навіщо закривати його тоді?

— користувач

6

не конструктивна? Так супер модники завдають удару знову.

— Аміт Трипаті

4

Станом на сьогодні майже 24 000 людей вважають це питання конструктивним. У тому числі і я.

— заморожений

3

Станом на 2017 рік, це питання все ще є конструктивним

— Леонардо Пессоа

140

Відповідно до книги "Джанго" , Джанго досить чітко слідує схемі MVC, щоб її можна було назвати рамкою MVC.

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

Більше про MTV / MVC можна прочитати тут:

Модель розвитку MTV (або MVC)

Якщо ви знайомі з іншими структурами веб-розробки MVC, такими як Ruby on Rails, ви можете вважати, що подання Django є контролерами, а шаблони Django - переглядами .

Це прикрою плутаниною, спричиненою різними трактуваннями MVC.

У інтерпретації Джанго MVC подання описує дані, які надходять до користувача; не обов’язково лише те, як виглядають дані, але які дані представлені.

На противагу цьому, Ruby on Rails та подібні рамки передбачають, що завдання контролера включає визначення того, які дані будуть представлені користувачеві, тоді як погляд суворо виглядає як дані, а не які дані.

— Паоло Моретті
джерело

6

Дякую за чудову відповідь. Переходячи з Рейки до Джанго, це відповідає на одне з речей, що мене найбільше засмутило: чому джанго ставить код контролера у файл, який називається views.py !?

— dgmdan

@dgmdan Це лише умова за замовчуванням, ви можете вибрати ім'я, яке вам подобається. Але я згоден, здається дивним :)

— Паоло Моретті

1

Я вважаю за краще залишити views.py як шар перегляду та створити набір класів контролерів у пакет контролерів, щоб уникнути плутанини Джанго.

— stanleyxu2005

5

@dgmda: Оскільки поняття "контролер" є неправильним у веб-сайтах. MVC - це система, орієнтована на події, яка не відповідає лише моделі HTTP REQUEST / RESPONSE без громадянства. В першу чергу це не слід називати MVC. Майже всі веб-карти не є MVC, але використовують модель та функцію чи клас, які зазвичай називають View. Перегляд у свою чергу може делегувати візуалізацію HTML шаблону, але цього не потрібно. Так що насправді немає контролера.

— Леннарт Регебро

2

Я повертаюсь до концепції Леннарта Регебро про те, що модель без громадянства на зразок HTTP не повинна мати контролер, а модель MVC для веб-сайтів просто призводить до великої плутанини

— Хуссам

23

Поширені питання про Django - це гідне місце для початку:

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

У нашій інтерпретації MVC "перегляд" описує дані, що надходять до користувача. Це не обов'язково, як вони виглядають, але які дані представлені. Перегляд описує, які дані ви бачите, а не як їх бачите. Це тонка відмінність.

...

Крім того, доцільно відокремлювати вміст від презентації - там, де надходять шаблони. У Джанго "перегляд" описує, які дані подаються, але перегляд зазвичай делегує шаблону, який описує, як дані подаються.

Куди ж вписується “контролер”? У випадку з Джанго це, мабуть, сам фреймворк: обладнання, яке надсилає запит у відповідний вид, відповідно до конфігурації URL-адреси Джанго.

Якщо ви голодні за абревіатурами, ви можете сказати, що Django - це рамка "MTV" - тобто "модель", "шаблон" та "перегляд". Ця поломка має набагато більше сенсу.

Майте на увазі, що «Контролер моделей перегляду» - це лише зразок, тобто спроба описати загальну архітектуру. Тож краще питання може бути: «Наскільки добре Django відповідає схемі контролера перегляду моделі?»

— Пол Д. Уейт
джерело

3

Це, мабуть, найбільш пряма відповідь.

— користувач

11

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

Програма viewDjango, як правило, є набором запитів для отримання даних і передає їх до шаблону.

— inigomedina
джерело

10

A viewsв Django - це щось на кшталт controllerMVC, а templateв Django швидшеviews

— Roel

7

У mvt запит на URL-адресу надсилається до представлення даних. Цей вигляд викликає модель, виконує маніпуляції та готує дані для виведення. Дані передаються в шаблон, який надається як відповідь. в ідеалі в веб-рамках контролер прихований від перегляду.

Ось де відмінність від MVC: у mvc користувач взаємодіє з gui, контролер обробляє запит та повідомляє модель та перегляд запитує модель для відображення результату користувачеві.

— Самуеле Маттіуццо
джерело