Первым делом определитесь чего вы хотите на самом деле. Не понятно почему отсутствие проверки родителя — непрофессиональность. Если она не нужна, то непрофессиональность как раз её написание ради какой-то абстрактной идеи. Например, для региона может быть нужно сделать отдельную страницу при наличии страны и отсутствии его самого («для указанной страны не существует такого региона»). Если все ошибки ведут на одинаковую надпись «страница не найдена», то дополнительные проверки ни к чему.
Далее надо определиться с реализацией. Но тут уже вам должно быть виднее какая у вас архитектура. По сути всё предложенное выше сводится к классическому паттерну Strategy: весь общий функционал оставляем в родительском классе, а все частности (ключевой момент — их должно быть мало) переносим в наследников. В вашем случае предком будет CRUDController с реализацией метеодов завязанной на modelClass, а потомками классы определяющие этот modelClass и метод checkRequest. Дёрганье checkRequest прописывайте где вам нравится. Не знаю как устроен Yii, но если он позволяет создавать контроллеры произвольных классов не наследуясь ни от кого, то имеет смысл вообще объявить CRUDController абстрактным и в нём же прописать абстрактный метод checkRequest. Тогда это будет вообще Strategy из книжки, а вы получите возможность использовать checkRequest в других методах CRUDController не опасаясь того что в наследниках он не определён. И ещё обычно в современных фреймворках есть метод, который дёргается перед любым экшеном контроллера. Возможно, там вашему checkRequest самое место.
Продолжая фантазировать на тему, можно сделать тип модели modelClass передаваемым в параметре. Или получать его исходя из того что вам передали. Только надо сделать карту допустимых значений. Что-нибудь типа
array(
...
'region' => array( 'model' => 'regionModel', 'parent' => 'countryModel' ),
'country' => array( 'model' => 'countryModel', 'parent' => null )
)
и из этой карты получать модель и родителя проходя по ключам массива и проверяя на существование параметра с таким ключом. Как только нашли — проверяем существование родителя и работаем по общим методам с уже определённым значением modelClass.
Почему все советуют делать Strategy. Потому что эта штука зарекомендовала себя в боях. Классический ООП подход часто приносит больше трудностей при разработке (надо быть аккуратнее и чаще всего писать больший объём кода), но даёт заметный выигрыш при необходимости изменить какую-то часть проекта. К примеру, «нафантазированный» способ реализуется быстрее (надо добавить пару методов и карту соответствия, против базового класса + 5 классов дочерних для сущностей). Но при этом если понадобиться добавить какой-то новый экшн (например, добавление комментария к ревью), то в случае со стратегией вы просто впишите его в нужный класс. А для более простого метода придётся ломать себе голову с изобретением исключения в логике. Пару раз так можно сделать, но… после 12 костылей код превратится в тыкву.
Но, в конечном итоге, решать всё-равно вам. Может быть и второй быстрый способ подойдёт, потому что «там стопудова ничего не будет меняться» (не верьте тем кто так говорит — обязательно будет). Может вы их скрестите и внесёте в базовый класс стандартную реализацию checkRequest, а в дочерних классах будете определять только modelClass и parentModelClass. Всё зависит от конкретных потребностей и архитектуры проекта.
Средний
