@sait4seo

Данные для views через класс Application, чем плохо?

//класс Приложения доступен во всех местах приложения
class Application {
    public $data = array();//сюда сохраняем данные выборок, для отображения во вьюхах
    ...
}
//подключаем вьюхи
function include_view($fileName, $vars = array())
{
    $app=Application::Instance();
    ...
    ob_start();
    include $fileName;
    return ob_get_clean();	
}

Далее где-то во вьюхе
<h1><?=$app->data['page']['h1']?></h1>
<?=include_view('subView.php'); ?>

Таким образом ни в модели, ни в контроллере не нужно перечислять передаваемые во вьюху переменные, преимущество в том что при доработке проекта не нужно следить, чтобы переменные обязательно прописывались в контроллере и модели. Минимизация правок.
Чем плохо? Кроме того что можно случайно затереть что-то в $app->data в каком либо модуле. Почему в популярных фрейворках жёстко прописаны переменные, и порой добавляя поле в таблицу приходится прописать переменную и закомитить ещё десяток файлов, а потом ещё писать костыли и городить огороды, чтобы отобразить в лэйауте (родительской вьюхе) переменную, которая была создана в модуле, который выводит отображение в локальную вьюху-виджет.
  • Вопрос задан
  • 290 просмотров
Пригласить эксперта
Ответы на вопрос 3
@Ramallah
На что только люди не идут, что бы не использовать фреймворки. Но это вопрос философский.

Для того, что бы полностью не затереть $app->data, сделай на них метод/сеттер. И будет по типу $app->set('variable','value') или просто $app->var = value;

Мало того, можно определенные выборки пораскидывать в трейты, и использовать в необходимых контроллерах.

Так же еще можно и через гетеры определять необходимость подгрузки данных. К примеру тебе надо только на части страниц показать какие-то данные А. Прописываешь по типу...

if (!isset($this->data['A']){
 $this->data['A'] = Foo::bar();
}
return $this->data['A'];
Ответ написан
He11ion
@He11ion
PHP-monkey
Потому что у Вас а) сильная связанность - когда каждая вьюха должна знать какие поля есть в app и какие ей нужны и б) при увеличении количества обработчиков этого app вы банально не сможете определить какая конкретно функция/класс пишет неверные данные. Используйте на практике принципы ООП, это здорово помогает.

Да, на небольшом проекте из 10 страниц разницы не видно, но если получается что-то большое и/или написанное несколькими людьми - будут проблемы.
Ответ написан
bitver
@bitver
Не знаю чем это плохо, хотя такой подход похож на использование глобальных переменных, отсюда и можно нагуглить чем это плохо.
А от себя могу добавить, что если идти стандартным путём и во вьюхе писать phpDoc-и или как там они называются, то у переменных будет автодополнение в IDE.
/** @var $someData \app\models\YourModel */
И другим разработчикам понятно что это такое сразу из View и не надо лезть в контроллер, чтоб посмотреть что за переменная.
Удобно, красиво, одно лишнее движение вначале и избегаем тысячи лишних в итоге.
Ответ написан
Комментировать
Ваш ответ на вопрос

Войдите, чтобы написать ответ

Войти через центр авторизации
Похожие вопросы