Это хорошая практика? По моему опыту да.
Следует иметь в виду, что любой контроллер может отображать несколько разных страниц. Например, рассмотрим «Панель мониторинга», которая может иметь несколько задач, каждая из которых требует наличия собственной страницы.
Грубый псевдо-codeish «Dashboard» контроллер может выглядеть следующим образом:
class Dashboard extends CI_Controller {
public function __construct(){
parent :: __construct();
$this->load->helper(array('form', 'url'));
$this->load->library('form_validation');
$this->load->model('somemodel_model');
}
public function index(){
//displays a task selection page with links to various tasks
}
public function admins(){
//some kind of interface to display and edit admin level users
}
public function users(){
//CRUD for dashboard users
}
}
С помощью этого контроллера страница выбора задачи открыта с baseurl/dashboard, стр Adminstrator с baseurl/dashboard/admins и пользовательским CRUD с baseurl/dashboard/users. Поскольку каждый из них имеет один и тот же класс, код, необходимый для всех/многие из этих страниц (например, проверка), может быть реализован в конструкторе и/или с частными методами. Вы, наверное, уже все это знаете. Имейте в виду, что ответчики AJAX также могут находиться в контроллере, используя ту же технику.
Что касается соблюдения правил валидации DRY и облегчения работы, необходимой для изменений правил, CI может хранить наборы правил в файле конфигурации для удобства повторного использования в нескольких ситуациях. Read about it.
У меня есть ваша точка зрения, но у меня мало путаницы. Можем ли мы полагаться на проверку на стороне клиента? Клиент всегда может пройти проверку, отключив javascript или играя с заголовками HTTP-запросов. Если модель называет другую модель, то не является ли нарушение SOC, поскольку сближение модели уменьшается? Можете ли вы предоставить мне ссылку или пример, описывающий подводные камни, позволяющие диспетчеру поговорить с несколькими моделями. Извините за задание слишком много вопросов. –
Да, вы можете положиться на проверки на стороне клиента. В основном вы отправляете свою форму только после прохождения всех проверок на стороне клиента. Если вы посмотрите на все основные веб-сайты, они в значительной степени полагаются на javascript. И только некоторые из них имеют версии, отличные от javascript. Что касается модельной модели вызова, то ее общепринятой практикой является сервис-сервис для бизнес-логики. Я не имею в виду DAO, призывающий DAO. DAO следует исключительно вызывать из своих соответствующих услуг. Наконец, я работал во многих веб-проектах, и мои ответы основаны на этом. У меня нет списка справочных сайтов. –
@KrrishRaj Проверка на стороне клиента можно опираться, но не может и, вероятно, не должна полностью исключать необходимость проверки подлинности на заднем плане. Модель для вызова модели, ИМО, явно нарушит SOC. С другой стороны, использование контроллером нескольких моделей показало бы мне, как вы создаете SOC. CodeIgniter позволит вам загружать модели внутри другой модели. Ловушка, с которой вы могли бы легко справиться, связана с проблемой зависимости. В частности, круговые ссылки - все, что легко построить. – DFriend