бамп

джанга не мвц, и вообще там много всякой "магии" понапичкано, что разобраться сходу там не получится

MVC никак не работает. То есть есть красивая идея о разделении зон ответственности, но в реальности однажды возникнет ситуация когда, скажем нужно будет из вьюшки обращаться к модели напрямую, то есть без контроллера, для какой-нибудь валидации полей модели на стороне клиента.

Но тебе все это пока знать ненужно. Просто думай об мвс как о паттерне программирования, т.е. есть у тебя логика относящаяся к модели; так описывай эту логику в соответствующей модели, но не в контроллере.

Нужно отобразить модель? Через контроллер создаешь нужный объект и передаешь во вьюху. Т.е. контроллер отвечает за связь моделей и вьюшек.

Это называется бак-енд.

Чтобы отобразить данные нужно уже во вьюхе писать соответствующий код. Код, который, возможно будет взаимодействовать с css, фреймворками типа angular и прочими хмтл-тегами.

Это фронт-енд.

Как видишь МВС сочитает в себе как фронт-енд (модели, контроллеры) и фронт-енд(представления). Но это не панацея, бывает на него кладут по тем-или иным причинам, что приводит к отсутствию четкого определения что же такое мвс. Отсюда забавные казусы, когда у десяти разных программистов будет разное понятие что же такое мвс.

Поэтому просто думай об МВС как о паттерне, а там дальше уже разберешься.

>>804211
я правильно понимаю, что мвс на бэке это чистый рест?
+ не по теме. недостаток с взаимодействием вьюхи и модели вполне обычно решается в мвп. Есть ли у мвп какие-либо серьезные недостатки по сравнению с мвс?
мимокрок

>>804077 (OP)
Давай сделаем лучше разбор на примерах. Я сейчас поддерживаю один проект на джанге, и он содержит кучу всякой хуйни, я для этого даже отдельный тред создавал.
Допустим, у нас есть некоторое множество объектов, которые каждый год начинают свою нумерацию с нуля (например, входящая корреспонденция от партнёров). Для того, чтобы каждый раз увеличивать счётчик, есть несколько путей.
1. На клиенте выводим таблицу, которая содержит список уже внесенных документов. Смотрим, сколько пикселов занимает одна строка, делим высоту div'а, в котором находится таблица, на неё, округляем, получаем примерное число строк в ней. Ну, теперь просто прибавим плюс 1. Так вот, это View - то, что выдаётся пользователю (хотя могло бы отдаваться мобильному приложению, и тогда это был бы API, а не UI).
2. Переопределяем у модели IncomingPost метод save(). Он должен каждый раз при сохранении вычислять количество уже имеющихся в БД моделей за этот год и в поле incoming_number записывать это число N+1. Это уровень модели. Проблемы: даже обновление записи будет увеличивать значение счётчика.
3. И есть третий уровень - контроллер. В Django это та логика, которая реализуется во View. Именно он выполняет обработку поступивших данных и выводит пользователю куски страницы. В зависимости от его поведения мы будем получать тот или иной результат. Главная фишка в том, что даже изменив модель, мы можем оставить наши представления без изменений, если внесем незначительные (при продуманной архитектуре проекта в целом) изменения.
На самом деле вряд ли ты такое где встретишь, будь готов к тому, что твоя работа будет выглядеть так, как показано на этом видео: https://www.youtube.com/watch?v=-8TH4CsSoQ8

>>804211
>бак-енд
>бак
>а
>>806270
>рест
Хуест, блядь. Какой еще рест?
>>806303
Макак, варианты 1 и 2 это ты серьезно?

>>806359
Absolutely. Именно так там и реализовано сейчас. Сделать ничего не могу, разработчики мычат типа "Ну мы же старались, делали, что же нам, переделывать что ли теперь?"

>>806303
>Эти варианты
Пиздец. Просто пиздец. От первого варианта бился в истерике.

>>806359
>Какой еще рест?
Ин пис который.

>>806476
посмотри сколько пикселов, ещё разок))

>>806359
ну там рест, ну когда эта ебола всякими апи через json свое состояние передает, ну не сердись ты так

>>806303
>Смотрим, сколько пикселов занимает одна строка, делим высоту div'а, в котором находится таблица, на неё, округляем, получаем примерное число строк в ней
А я думал, что я говнокодер

>>806866
Ладно, посоны, первый вариант - это дичайший пример того, как делать НЕ надо, но бывает и такое. Например, на портале госуслуг моего Мухосранска Липецк очень охуенно были когда-то сделаны кнопки для перехода между формами. Текст был нарисован в Paint'е, этот img был положен на span, который был вложен в несколько div'ов, на самый верхний из которых вешался обработчик onClick. К счастью, я сейчас далёк от проверки работоспособности этих сервисов в связке с сервисами того софта, что я поддерживал, но осадочек остался.
Надеюсь, однажды весь портал перепишут на Angular и уже никто не будет страдать такой фигней.