Dreaded

Обычно junior реализовывать никакие не умеет, и максимум названия знает:)

Мое мнение таково. Будет хорошо, если вы один два будете знать. Но знать так, что сможете объяснить для чего его применять. Ну и конечно же реализовать небольшой пример.

UPD:
> Это нормально что в контроллере столько много catch'eй?
Не то чтобы нет, но "попахивает".
> как быть, если у меня возникает несколько исключений, и я хочу выдать пользователю информацию о всех возникших сразу

У вас смешана валидация входных параметров с возникновением нештатных ситуаций.
Exception стоит кидать если метод не может вернуть осмысленный результат.
Ошибки валидации ("сообщение слишком длинное", "файл не того расширения") можно собирать, к примеру, в массив. Как валидировать входные данные выходит за рамки этого вопроса.
------
> Можно ли так делать?
Попробуйте использовать правило 5 почему (ну или "зачем") чтобы попытаться добраться до сути.

- Я даю отдельные имена исключениям.
- Зачем?
- Для того что бы отловить различные ошибки.
- Зачем отлавливать различные типы ошибок?
- Чтобы показывать разные сообщения.
- Зачем показывать разные сообщения?
- Чтобы пользователь мог отреагировать определенным образом на конкретный тип ошибки
(решить что ему делать в случае конкретного исключения).

Давайте посмотрим что человек (пользователь) на вашем сайте (системе) может сделать в случае ошибки:
1. Не корректное сообщение.
Привести его к корректному (сделать его короче, как-то отформатировать и т.п.)

2. Не удалось загрузить файл.
Если файл слишком большой - можно попробовать загрузить файл поменьше.
Если это внутренняя ошибка (например: закончилось место на диске на сервере, нет прав на запись и т.п) - то ничего, здесь уже требуется вмешательство тех кто обслуживает систему.

3. Ошибка PDO.
Ничего, это внутренняя ошибка.

Т.е. есть смысл создавать новый тип исключения, если пользователь системы может иначе отреагировать на этот тип.

Я использую 2 типа исключений на уровне web-слоя: внешние и внутренние.
Внешние - если пользователь может повлиять на них (страница не найдена, файл слишком большой, нет доступа и т.п.).
В них сообщение показывается пользователю как есть. Подноготная (пути к файлам, пароли, названия БД и т.п) в такие ошибки не вкладывается.

Внутренние - пользователь не может влиять (ошибка подключения к БД, SQL syntax error и т.п).
Пользователю показывается только код ошибки. В такие ошибки также вкладываю техническую информацию.

Ты (как программист) также можешь быть пользователем какой-то системы (к примеру, библиотеки).
Например, библиотеки для работы с БД.
Предположим ты импортируешь csv-файл в базу, заполняешь числовую колонку и вместо числа у тебя попадается текст.
Запрос падает с ошибкой и тебе не плохо бы отличать её от ошибки синтаксиса.
Если попался текст вместо числа - то можно просто пропустить строку.
Если ошибка синтаксиса - то у ошибка в коде и продолжать импорт нет смысла.

Подытожу:

> Можно ли создавать свои пустые классы Exception'ов наследуемые от класса Exception только лишь для того что бы было отдельное имя исключения?

Можно.

Сколько делать отдельных исключений?
Зависит от того как их будет обрабатывать пользователь.
Если твой контроллер(модель, подсистема) кидает множество разных ошибок и все они обрабатываются одинаково - то стоит призадуматься.

Практика хорошая. Именно так и стоит делать. В идеале у каждой ошибки должен быть свой уникальный эксепшн. Например, от FileException можно наследовать например NotFoundFileException и AccessFileException. При этом тело классов в большинстве случаев будет пустым.

А вот то, что ты пытаешься поймать все возможные эксапшны в контроллере - это совсем не хорошо. По хорошему нужен отдельный эксепшн хендлер для этого.

Похоже на российские тендеры - как будто написано под конкретного человека, чтоб взять на работу только его и никого больше, сложно найти второго такого у которого будет совпадать IDE в котором он редактирует код, социальные сеточки, настолько категоричный отказ воспринимать PHP как интерпретатор, которым его задумывал создатель и т.п. Пара хороших пунктов есть, но больше мимо и многое не упомянуто ... я бы джуниора в первую очередь про SQL-injection спросил или хотя бы про базовый синтаксис INSERT-a, тут на тему БД вообще ничего нет, при том, что есть требование ORM и фреймворка.

• в модель должны попадать чистые данные (то есть таки да - -в контроллере)
  
• вообще с голым _POST не нужно в 2018 году работать, посмотрите это видео: https://vk.cc/8dAijK
  
• валидацией может заниматься модель, но в данном случае МОДЕЛЬ ВАЛИДАЦИИ, а не модель сущности,
  модель -- это целый слой, а не конкретный класс или вид классов, это и сущности и сервисы и валидация и т.д....
  

POST в моделе
Не правильно работать с _POST в моделе, тк модель -- по сути синоним вашего бизнеса, бизнес модель, мне кажется странным было бы, если в магазине были бы продавцы, товары, операции дать денег и взять сдачу, данные (купюра, скидка)
и тут же некий _POST запрос (ну или некая звуковая информация для операций (с битрейтом и частотой:):) мне кажется в бизнес-процесс должно попадать число или купюра, которое обработает некий контроллер (глаз, ухо и продавец в целом как валидатор)

Валидация в сеттере
По поводу сеттеров и валидации -- тоже плохо
Купюра должны быть проверена в момент ее передачи, а не когда вы уже дали товар, посчитали сдачу, напечатали чек).. аналогия может быть немного не точной, но понятен принцип -- не в сеттере :)

Ну или как пример -- договор между юрлицами, когда вы договорились и заполняете договор, для подписей (по сути сеттер ваш абстрактный) вы УЖЕ ДОЛЖНЫ были проверить контрагента и условия этого самого договора

Польза абстракций

Мне кажется так получается гораздо сложнее чем просто в каждом сеттере прописать валидацию. В общем, объясните, пожалуйста, как это реализовать и в чём плюс такого подхода

Если каждый раз писать валидацию, то нужно каждый раз ее писать :)
Если вынести это в отдельную прослойку, то за валидацию будет отвечать отдельный слой, которому вы просто скармливаете поля и их правила -- это упрощает работу с задачей "валидировать" -- вы можете этот слой чинить и усложнять, а сеттеры будут чистыми и не будет копипаста со всеми проблемами -- дублирваоние (забыл, не углядел и прчоее)

Смотрите как валидация делается в Ларавел:

public function rules()
    {
        return [
            'name' => 'required|string|max:255',
            'email' => 'required|string|email|max:255|unique:users',
            'password' => 'required|string|min:6|confirmed',
        ];
    }

Логичнее вынести все в ajaxController() и работать в нем только с запросами аякса, это в частности позволяет в конструкторе контроллера не вызывать кучу специфических для данного раздела методов, а так же сразу определить для вью соответствующий лэйаут, однако это как раз не всегда удобно. По этому у меня есть аякс контроллер, в который я отсылаю только аякс запросы общего назначения, не привязанные к какому то конкретному разделу(в конструкторе сразу можно обработать тип и сделать ексит если не аякс), а запросы с более четким типом, например работа с пользователем, идет в свой контроллер, и уже в экшене проверяется тип запроса и производятся нужные действия. Это немного более накладно по ресурсам(из за конструктора с доп. функционалом), но более удобно в плане "все подобное в одном месте".
На уровне роутера имхо никаких обработок быть не должно, его задача отдать роут, а контроллер уже создает логику ответа.

Добавьте стандартному контроллеру функцию определения типа запроса из хедера и в зависимости от этого выдавайте содержимое View либо чистый Json.

Пока что я вижу такой вариант: в контроллере получаю данные модели, создаю объект класса View(там же в методе контроллера) и с его помощью подключаю необходимый шаблон

Обычно так и делают, вью определяют в конструкторе как свойство контроллера, отовсюду изнутри контроллера соответственно он виден как $this->view; Шаблон обычно в виде прописан по умолчанию(что бы не дергать каждый раз набор из шапки, футера, слайдера етц), а вот контент в него "рендерится", и обычно берется из папки вьюшек с тем же именем что и контроллер+экшн. это сильно упрощает подключение вьюх, достаточно вызвать метод $this->view->renderView(); и в шаблон по умолчанию в определенном месте рендерится вьюха из нужной папки с нужным именем(например /engine/view/index/index.tpl для индекс контроллера + индекс экшна). Это как вариант.

Есть разные трактовки этой концепции. И в общем то она не обязательно подразумевает разделение на файлы.

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

Не всё должно относится к модели, представлению или контроллеру. Ваш класс, например, обслуживает представление, но сам им не является.

Этот код вполне заслуженно выделен в отдельный класс, а в какую папку его поместить - решать вам.

Лучшие на YouTube скринкасты по Gulp и Webpack.

В своё время искал ответы на такие вопросы, как структура папок и файлов для веб-сайта и был очень рад, когда из нескольких источников узнал и совпали ответы по структуре в виде папок - html, css, img, js и решил, что теперь понимаю структуру веб сайта.

Когда узнал про сборщики проектов - не понимал, что там собирать то?

И только когда пришло время делать сайты по 50 страниц и плюс адаптивные их версии - то сразу решились вопросы и со структурой сайтов и сборщиками проектов и с шаблонизаторами и с препроцессорами и ещё много с чем.

Как только придёт время и вы столкнётесь с необходимостью использовать какой то инструмент - то и решение с выбором и использованием не заставит себя долго ждать.