Не знаю, каким боком тут урл, но модель — это данные, контроллер — код, обрабатывающий данные. В терминах веб-фреймворков, моделью может быть код, непосредственно вытаскивающий данные (орм например), а контроллер подготовит их к отправке клиенту. Впрочем, модель очень часто объединяют с контроллером, это крайне распространённая практика.

Чтобы PDF рендерить.

это если у тебя одна модель, а если нужно чтобы в рамках экшна было обработано несколько моделей, создать доменные события, обработать исключения? все это складывать в модель было бы неправильно. К тому же, зачем модели знать о view? тогда получиться какой-то god object

Модель не содержит логики, это просто данные описывающие предметную область. View отображение этих данных, обработка ввода, трансформации, валидации помещают в контроллер.

Модель не содержит логики, это просто данные описывающие предметную область

ЛОЛ ЧТО? Модель может вообще не содержать данных. Она именно что представляет собой абстракцию предметной области, а уж как оно устроено дело десятое. В т.ч. модель может быть исключительно вычислительной. И уж конечно именно модель в любом случае содержит всю логику относящуюся к предметной области. Контроллер должен только управлять потоками данных между моделями и представлениями.

контроллер просто направляет нас в модель, рез-т вернется обратно в контроллер и контроллер вернет его во view. Зачем посредник

Ну а кто будет направлять данные в модель, а потом результат работы модели в представление? Модель и представление не должны знать, как и откуда у тебя данные берутся. Хрен знает как ты там из парсишь из запроса.

И уж конечно именно модель в любом случае содержит всю логику относящуюся к предметной области.

Для меня модель это либо DOM либо DTO без бизнес логики, а бизнес логика вынесена отдельно в какой нибудь слой, я в основном круды на жабе пишу.

Если можно сразу url перенаправить в модель, там все выполниться и вернуть это все из модели в шаблон. Ведь контроллер просто направляет нас в модель, рез-т вернется обратно в контроллер и контроллер вернет его во view. Зачем посредник?

Чтобы можно было выкинуть все эти твои урлы с шаблонами кхуям и вместо них прицепить к модели какой-нибудь мобильный интерфейс.

В идеале модель не зависит ни от каких фреймворкоф, баз данных, деталей типа урлов.

Пример для тупых – игра «дурак». Твоя модель – это классы «игрок», «карта», «колода», методы «положить карту», «взять карту», в методе «положить карту» исключение, если карта ложится на карту другого цвета и не является козырем, вот это всё.

Задача контроллера – управлять моделью. Если ты в вебе, то тебе например пришло в хттп-запросе «Пользователь номер 3 положил карту номер 8 на карту номер 44». Контроллер парсит все эти номера из запроса, и вызывает соответствующие методы.

Задача вида – прочитать новое состояние модели и послать хттп-ответ назад.

Завтра ты решил, что веб – хуита и надо писать мобильное приложение. Пишешь новый контроллер, который обрабатывает координаты пальцевозюкания вместо хттп-запросов, пишешь вид с каким-то мобильным гуем, пихаешь туда уже готовую модель и рубишь баблосы.

модель это либо DOM либо DTO без бизнес логики, а бизнес логика вынесена отдельно в какой нибудь слой

Т.о. у тебя модель намазана слоями. Что в общем вполне возможно. Никто ж не настаивает, что модель должна быть монолитная.

Хреновая модель. Как в таком случае реализовать поддержку двух карточных игр типа дурак обычный и дурак переводной?

Чтобы можно было выкинуть все эти твои урлы с шаблонами

Или выкинуть MVC прослойку на мороз и строить архитектуру ближе к сути.

Пишешь новый контроллер, который обрабатывает координаты пальцевозюкания вместо хттп-запросов,

Ага

Пишешь новый контроллер

«Вся суть»

Если можно сразу url перенаправить в модель,

И да, url – и есть модель (точнее, часть модели), если попытаться выразить в сущностях MVC.

чтобы ловить события изменения данных

Хреновая модель. Как в таком случае реализовать поддержку двух карточных игр типа дурак обычный и дурак переводной?

А что тебя смутило?

function подкинуть() {
  if (!this.переводной)
    throw new Error('Иди нах, Палыч, мы в обычного играем!');

*перевести()

Или выкинуть MVC прослойку на мороз и строить архитектуру ближе к сути.

Для бложиков, у которых url – часть модели, так и надо.

Модель - бизнес логика и/или данные. Контроллер - служебный код, например, валидация данных. Как раз важно разделение кода на служебный (не содержащий логику) и код с логикой.

О какой валидации идет речь?

Можно простой пример?

Я как новичок не понимаю назначение контроллера. По мне так можно запрос сразу отправлять модели и далее из нее вызывать шаблон.