Что такое mtv в django
Разделение кода¶
В программном обеспечении принято разделять: программную логику, код, который относится к данным, настройки и шаблоны. Таким образом, код становится более структурированным, и его легче развивать, а также сопровождать в дальнейшем.
MVC (Model-View-Controller: модель-вид-контроллер) — шаблон архитектуры ПО, который подразумевает разделение программы на 3 слабосвязанных компонента, каждый из которых отвечает за свою сферу деятельности.
Бешеная популярность данной структуры в Веб-приложениях сложилась благодаря её включению в две среды разработки, которые стали очень востребованными: Struts и Ruby on Rails. Эти среды разработки наметили пути развития для сотен рабочих сред, созданных позже.
Паттерн MVC (Model-View-Controller)
Классические MVC фреймворки:
Фреймворк Django ввел новую терминологию MTV.
TADA!! Django invented MTV
Паттерн MTV (Model-Template-View)
В защиту своего дизайна авторы Pyramid написали довольно большой документ, который призван развеять мифы о фреймворке. Например, на критику модели MVC в Pyramid следует подробное объяснение, что MVC «притянут за уши» к веб-приложениям. Следующая цитата хорошо характеризует подход к терминологии в Pyramid :
«Мы считаем, что есть только две вещи: ресурсы ( Resource ) и виды ( View ). Дерево ресурсов представляет структуру сайта, а вид представляет ресурс.
«Шаблоны» ( Template ) в реальности лишь деталь реализации некоторого вида: строго говоря, они не обязательны, и вид может вернуть ответ ( Response ) и без них.
Нет никакого «контроллера» ( Controller ): его просто не существует.
«Модель» ( Model ) же либо представлена деревом ресурсов, либо «доменной моделью» ( domain model ) (например, моделью SQLAlchemy), которая вообще не является частью каркаса.
Нам кажется, что наша терминология более разумна при существующих ограничениях веб-технологий.»
Паттерн RV (Resources-View)
Также протокол HTTP не позволяет хранить состояние и отправлять/принимать оповещения клиенту от сервера, что ограничивает возможность отслеживания действий клиента для последующего уведомления модели на изменение состояния.
Пример MVC блога¶
Структура файлов¶
Приведем структуру нашего блога к следующему виду:
Модель MTV. Маршрутизация. Функции представления
Давайте подробнее разберемся как в Django работает механизм обработки запросов от пользователя. Нам это понимание пригодится в дальнейшем, описывая отдельные элементы всей этой процедуры.
Смотрите, вначале, когда запрос приходит на фреймворк, он пропускается через блок маршрутизации:
Здесь фиксируется тип URL-адреса и в списке шаблонов предопределенных адресов ищется первое совпадение. Например, пользователь вводит запрос:
Это есть не что иное, как главная страница сайта, фактически пустой запрос без параметров. Следующий запрос:
Это уже другой маршрут. Или такой запрос:
И так далее. У нас может быть прописано множество типов URL-адресов и каждый адрес связан со своим обработчиком – представлением (иногда его еще называют контроллером). Если текущий запрос от пользователя не совпал ни с одним предопределенным URL, то возвращается код ошибки 404 – страница не найдена.
Предположим, что маршрутизатор нашел совпадение. Далее, активизируется представление, связанное с найденным типом URL-адреса. Представление (иногда его еще называют контроллером) – это или функция или класс, который отвечает за формирование ответа на соответствующий запрос. Как правило, ответом является HTML-страница. Эта страница, затем, возвращается клиенту, и он ее видит в браузере. Так вот, чтобы контроллер мог сформировать страницу, в общем случае, требуются данные (информация), плюс шаблоны, в которые эти данные упаковываются. Например, приходит запрос на вывод страницы о Мадонне:
Активизируется соответствующее представление, которое берет шаблон информационной страницы и наполняет ее данными об этой певице, хранящиеся в БД:
На выходе получаем сформированную HTML-страницу, которая и возвращается пользователю. Вот такое разделение на данные (model), шаблоны (templates) и представления (views) представляет собой общеизвестный паттерн MTV, то есть, разделение данных и HTML-шаблонов. Техника довольно эффективна и удобна, так как позволяет независимо наполнять БД информацией и параллельно разрабатывать или изменять функционал сайта. Кроме того здесь легче находить ошибки, в отличие от подхода, когда в одном скрипте присутствует и подключение к БД и оперирование шаблонами. Методика «разделяй и властвуй» очень хорошо себя зарекомендовала в мире программирования и довольно часто используется в том или ином виде.
Добавление первого приложения
Отлично, я думаю общие принципы работы фреймворка Django вам понятны. Но пока наш сайт пустой, он не будет реагировать ни на какие запросы пользователей, кроме тестовой главной страницы. Какой должен быть наш следующий шаг? Согласно философии Django мы должны создать новое приложение в рамках нашего сайта. Что это за приложение и зачем оно вообще нужно? Разработчики фреймворка решили, что каждая самостоятельная часть сайта должна представляться в виде своего отдельного приложения. Например, создавая информационный сайт, мы должны будем определить приложение для отображения страниц этого сайта по определенным запросам. Далее, к нам приходит руководитель проекта и сообщает, что еще нужно реализовать форум на сайте. И, так как это функционально независимая часть сайта, то мы создаем еще одно приложение для форума. Затем, руководитель почесал свою репу и вспомнил, что еще нужно сделать раздел с опросом пользователей по разным тематикам. И на сайте появляется еще одно приложение – для опроса. И так далее. Каждая логически и функционально независимая часть сайта предполагает его реализацию в виде отдельного приложения:
Приложения в Django следует реализовывать максимально независимыми, в идеале – полностью независимыми, чтобы в дальнейшем мы могли их просто скопировать в другой сайт и там оно сразу же начинало бы работать. Это не всегда удается, но нужно к этому стремиться.
Итак, давайте создадим в нашем сайте первое приложение, которое возьмет на себя базовый функционал, то есть, оно и будет являться ядром нашего сайта. Для этого я открою терминал и, находясь в каталоге django/djsite/coolsite, выполню команду:
python manage.py startapp women
Здесь startapp – команда для создания нового приложения; women – название приложения. Название может быть любым (мы его придумываем сами), но так, чтобы оно отражало суть своего функционала. В данном случае приложение women (женщины) будет формировать станицы сайта об известных женщинах из разных областей жизни: кино, спорт, музыка, политика.
После создания приложения его необходимо зарегистрировать в проекте нашего сайта, чтобы фреймворк Django «знал» о его существовании и корректно с ним работал. Для этого нужно перейти в пакет конфигурации сайта (coolsite), открыть файл settings.py и в списке INSTALLED_APPS прописать новое приложение. В нем уже прописаны несколько стандартных приложений самого фреймворка и к ним мы просто добавим свое:
По идее этого вполне достаточно и все будет работать, но в действительности Django обращаясь к этому пакету находит файл apps.py, откуда и берет настройки приложения из класса WomenConfig. Чтобы в дальнейшем каждый раз не конкретизировать этот путь, я пропишу его сразу в списке приложений:
Представления и маршрутизация
Все, приложение создано и зарегистрировано. Давайте теперь создадим обработчик главной страницы сайта. Для этого нужно определить представление этой страницы. Как я уже отмечал, представления в Django можно реализовывать или в виде функций или в виде классов. Давайте для начала воспользуемся функцией, как наиболее простой реализацией для понимания. Эта функция будет отвечать за формирование ответа для главной страницы приложения women и называться index (название может быть любым, мы его определяем сами):
Здесь указывается первый обязательный параметр request – это ссылка на экземпляр класса HttpRequest, который содержит информацию о запросе, о сессии, о куках и так далее. То есть, через переменную request нам доступна вся возможная информация в рамках текущего запроса.
На выходе эта функция должна возвращать экземпляр объекта HttpResponse, который будет автоматически формировать нужный заголовок ответа, а содержимое HTML-страницы будет определяться указанной строкой.
Теперь нам нужно связать эту функцию представления главной страницы с соответствующим URL-адресом. Для этого в пакете конфигурации coolsite откроем файл urls.py и в список адресов urlpatterns добавим новый путь с помощью специальной функции path:
Здесь первый параметр – это суффикс URL-адреса, то есть, часть URL, которая добавляется после доменного имени (при этом в конце ставится слеш). Например, если наш сайт располагается по адресу
то первый аргумент ‘women/’ добавляется в конце к этому пути:
Именно такой адрес мы сейчас и определяем. Второй аргумент – это ссылка на функцию представления, которая должна возвращать ответ на данный запрос. Как мы уже знаем, ответ формируется в виде экземпляра класса HttpResponse.
Теперь нам нужно импортировать функцию index, чтобы она была доступна в пакете конфигурации:
Если интегрированная среда вам здесь указывает ошибку, то это потому, что рабочим каталогом следует указать проект coolsite.
Проверим работоспособность нашего нового приложения и маршрута. Запустим тестовый веб-сервер:
python manage.py runserver
И откроем страницу:
В рамках этого приложения мы можем определять сколько угодно таких функций, связанных с разными URL-адресами. Например, пропишем еще одну функцию отображения списка статей по рубрикам:
Мы здесь используем тег h1, чтобы браузер отобразил эту строку как заголовок первого уровня. Затем, добавляем еще один путь в список urlpatterns:
И делаем импорт всех функций из модуля views нашего приложения:
Все, у нас появился новый URL-адрес:
по которому отображается заголовок первого уровня. По аналогии мы можем добавлять самые разные URL в наш сайт.
Обратите внимание, как только мы добавили дополнительные маршруты, тестовая главная страница перестала выдаваться, вместо этого мы видим исключение 404 – страница не найдена. Чтобы задать маршрут для главной страницы, нужно вместо «women/» записать пустую строку:
Здесь пустая строка как раз и соответствует маршруту главной страницы и теперь при обращении к ней будет вызываться функция представления index.
Однако такой подход, когда мы маршруты приложения прописываем в пакете конфигурации, нарушает принцип независимости приложений. Действительно, если мы захотим перенести приложение women на другой сайт, то нам придется дополнительно копировать и его маршруты, что не очень удобно и хорошо. Как это можно разрешить? Очень просто. Django позволяет вторым параметром вместо функции представления передавать список URL-адресов приложения и связанные с ними функции. Для этого мы сначала импортируем специальную функцию include:
А, затем, в списке маршрутов с ее помощью подключим список URL уже из нашего приложения women:
Мы здесь в качестве параметра указываем строку, в которой сначала записываем имя приложения и через точку файл urls, где будут прописаны маршруты приложения women. Ну а дальше все просто. Мы добавляем в приложение новый файл urls.py и в нем формируем список urlpatterns:
Здесь мы, во-первых, импортируем функцию path, которая и связывает URL c функциями представления и, во-вторых, импортируем функции из модуля views текущего пакета. Далее, в списке urlpatterns вызываем функцию path, первым параметром указываем пустую строку, а вторым функцию index. Как вы думаете, какому URL-адресу будет соответствовать эта пустая строка? Смотрите, в основном пакете конфигурации у нас указано, что адреса в ‘women.urls’ следует добавлять как суффикс к адресу ‘women/’, то есть, к адресу:
Поэтому пустая строка в нашем приложении будет ссылаться именно на этот URL-адрес. Давайте проверим. Запустим веб-сервер и откроем эту страницу. Да, мы видим, что отработала именно функция index.
Если же мы добавим еще один маршрут в наш список приложения:
То у нас появится еще один маршрут:
Как видите все достаточно просто и при этом мы получили относительную независимость нашего приложения women от основного проекта сайта.
На этом мы завершим начальное рассмотрение построения маршрутов и определения функций представления. Далее мы еще вернемся к этой теме и посмотрим, как можно использовать классы в качестве обработчиков запросов, какие дополнительные параметры имеются у функции path и некоторые другие моменты.
Видео по теме
#2. Модель MTV. Маршрутизация. Функции представления
#3. Маршрутизация, обработка исключений запросов, перенаправления
#4. Определение моделей. Миграции: создание и выполнение
#6. Шаблоны (templates). Начало
#7. Подключение статических файлов. Фильтры шаблонов
#8. Формирование URL-адресов в шаблонах
#9. Создание связей между моделями через класс ForeignKey
#10. Начинаем работу с админ-панелью
#11. Пользовательские теги шаблонов
#12. Добавляем слаги (slug) к URL-адресам
#13. Использование форм, не связанных с моделями
#14. Формы, связанные с моделями. Пользовательские валидаторы
#15. Классы представлений: ListView, DetailView, CreateView
#16. Основы ORM Django за час
#18. Постраничная навигация (пагинация)
#19. Регистрация пользователей на сайте
#20. Делаем авторизацию пользователей на сайте
#21. Оптимизация сайта с Django Debug Toolbar
#22. Включаем кэширование данных
#23. Использование капчи captcha
#24. Тонкая настройка админ панели
#25. Начинаем развертывание Django-сайта на хостинге
#26. Завершаем развертывание Django-сайта на хостинге
© 2021 Частичное или полное копирование информации с данного сайта для распространения на других ресурсах, в том числе и бумажных, строго запрещено. Все тексты и изображения являются собственностью сайта
Русские Блоги
Подробное объяснение режима MTV в Django
Справочный блог: https://www.cnblogs.com/yuanchenqi/articles/7629939.html
Во-первых, модель MVC
Знаменитый паттерн MVC в области разработки веб-серверов.
Так называемый MVC разделяет веб-приложения на три уровня: модель (M), контроллер (C) и представление (V), которые связаны подключаемым модулем и слабо связаны.
Модель отвечает за сопоставление бизнес-объектов и базы данных (ORM), представление отвечает за взаимодействие с пользователем (страницей), контроллер принимает ввод пользователя и вызывает модель и представление для выполнения запроса пользователя. Принципиальная схема выглядит следующим образом:
Два, модель MTV
Django’s MTV означает:
Модель :Быть ответственным за Бизнес-объекты и объекты базы данных (ORM)
Шаблон : Ответственный за то, как Отображение страницы Пользователям
Как правило, пользователь инициирует запрос к нашему серверу через браузер, и этот запрос возвращается к функции просмотра (если вызов данных не задействован, функция просмотра возвращает шаблон, который является веб-страницей для пользователя), функция просмотра Модель вызывается, модель выполняет поиск данных в базе данных, а затем шаг за шагом возвращает.Функция просмотра заполняет возвращенные данные в пустые места в шаблоне и, наконец, возвращает веб-страницу пользователю.
Три, основные команды Django
1. Загрузите Django
2. Создайте проект django.
Проект mysite будет создан в текущем каталоге, в котором выполняется команда.Структура каталогов следующая:
3. Создайте приложение в каталоге mysite.
4. Запустите проект django.
Итак, наш джанго запущен! Когда мы заходим по адресу: http://127.0.0.1:8080/, мы видим:
5. Синхронно изменять таблицы или поля базы данных (миграция базы данных)
Этот метод может создать таблицу. Когда вы добавляете новый класс в models.py, вы можете запустить его для автоматического создания таблицы в базе данных, не создавая ее вручную.
6. Очистите базу данных.
Эта команда спросит, да или нет. Если да, онаВсе данные очищены, Оставив только пустой список.
7. Создайте суперадминистратора.
8. Терминал среды проекта Django
(1) Терминал оболочки
(2) Терминал базы данных
Django автоматически войдет в базу данных, установленную в settings.py, если это MySQL или postgreSQL, он запросит пароль пользователя базы данных.
В этом терминале могут выполняться операторы SQL базы данных. Если вы знакомы с SQL, вам может понравиться этот подход.
9. Просмотр дополнительных команд
Просмотр всех команд, очень полезно, когда вы забываете под именем.
10. Конфигурация статического файла
(1) Развертывание производственной среды для обработки веб-сервера (nginx)
Статические файлы обрабатываются веб-сервером, а сам Django не обрабатывает статические файлы. Простая логика обработки следующая:
Выше приведен метод обработки после развертывания на веб-сервере. Чтобы облегчить разработку, Django предоставляет механизм обработки статических файлов в среде разработки.
(2) Статическая конфигурация среды разработки
Статические в основном относятся к таким файлам, как css, js, изображения:
Примечание 1. Django сопоставляет ссылочное имя и фактическое имя. При цитировании вы можете использовать только ссылочное имя, а не фактическое имя.
Русские Блоги
Обзор MTV в Django
Обзор MTV
Соедините M и T через V, пользователь обращается к серверу через T (интерфейс) (отправить запрос), T передает запрос V (планирование), V вызывает M (модель данных) для получения данных и отправляет данные в шаблон T Выполните визуализацию, а затем верните визуализированный шаблон пользователю.
Понимание MVC и MTV framework
1. Просмотры
Создайте функцию ответа маршрута в [каталог приложения / views.py]
Зарегистрируйтесь в [каталог приложения / urls.py]
Включить [URL-адреса приложений] в [URL-адреса проектов]
2. Шаблоны
Создайте шаблон папки templates в корневом каталоге проекта
Зарегистрируйте папку шаблона в [директория проекта / settings.py]
Создайте xxx.html под шаблонами
Вернуть обработанный шаблон в функцию ответа
Доступ к статическим ресурсам
Встроенный HTML-шаблон Django: 
3. Модели
Определите модель данных
Модель тестовых данных
Войдите в оболочку Python
python manage.py shell
from App.models import *
from datetime import *
Добавить, удалить, изменить и проверить
Установить значение атрибута
Ассоциация объекта (внешний ключ)
Получить всех первоклассников
Настроить правила маршрутизации в URL
Вызов функций в моделях для запроса в представлениях
Русские Блоги
Это Django MVC или MVT? И разница между MVC и MVT
Недавно меня смутили некоторые вопросы: следит ли Django за MVC или MVT? В чем разница между MVC и MVT? Может ли MVC продолжать раскол?
Я просмотрел много не связанных между собой статей в Интернете. Это не что иное, как то, что обозначают M, V и C, и то, что обозначают M, V и T соответственно. Эти поверхностные пояснения предназначены для программистов. Это не только не решит проблему, но и увеличит путаницу. Поэтому, проверив некоторую информацию, подводите итоги исходя из личного понимания, помните, что это только личные взгляды и позиции.
Как появился MVC? Что это?
Вначале MVC была идеей, все записанной как Model-View-Controller, и ее основной идеей было: разделение труда и развязка, чтобы уменьшить связь между различными блоками кода, повысить масштабируемость и переносимость кода, достичь Обратная совместимость.
Позже эта идея разделения труда приветствовалась все большим числом разработчиков и широко использовалась в разработке программного обеспечения, став моделью архитектуры программного обеспечения (если вы понимаете ее как программное обеспечение). Архитектурная модель, я всегда чувствую себя немного надуманным).
Разница между рамкой и дизайном рисунка
Наконец, идея MVC применяется к разработке WEB, которая называется WEB MVC framework.
Содержание MVC:
Является ли каркасный шаблон Django MVC или MVT?
Содержание MVT:
Процесс распространения URL-адреса. После получения запроса пользователя и параметров платформа Django сопоставляет URL-адрес с помощью регулярного выражения и перенаправляет его в соответствующее представление для обработки. Просмотрите вызовы M для обработки данных, а затем вызовы T для возврата к интерфейсу браузера.
Сделайте снимок, чтобы увидеть отношения между MVT и дистрибьютором URL:
Преимущество этой архитектурной модели заключается в том, что часть контроллера, которая принимает пользовательский ввод, обрабатывается самой платформой. Django уделяет больше внимания моделям (моделям), представлениям (представлениям) и шаблонам (шаблонам). Различные компоненты слабо связаны. Каждое веб-приложение, управляемое Django, имеет четкую цель и может быть изменено независимо, не затрагивая другие части.
Мой вывод
Django должен следовать идее MVC, но в конкретной реализации Django является режимом фреймворка MVT, и можно сказать, что MVT и Django тесно неразделимы, и именно использование Django режима архитектуры MVT вызвало у нас путаницу.
“What the heck is MVC? groan. Guess that’s one more fricking thing I have to learn!”
«Что такое MVC?Пожаловаться, Я думаю, что это еще одна скучная вещь, которую я должен изучить! «
no, you don’t have to learn about MVC because it’s more than likely going to confuse you and lead to more questions than answers
Нет, вам не нужно изучать MVC, потому что он может сбить вас с толку и вызвать больше вопросов, чем ответов.