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

Question

[Иван]

//класс Приложения доступен во всех местах приложения
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 в каком либо модуле. Почему в популярных фрейворках жёстко прописаны переменные, и порой добавляя поле в таблицу приходится прописать переменную и закомитить ещё десяток файлов, а потом ещё писать костыли и городить огороды, чтобы отобразить в лэйауте (родительской вьюхе) переменную, которая была создана в модуле, который выводит отображение в локальную вьюху-виджет.

Answer 1

[Ramallah]

На что только люди не идут, что бы не использовать фреймворки. Но это вопрос философский.

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

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

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

if (!isset($this->data['A']){
 $this->data['A'] = Foo::bar();
}
return $this->data['A'];

Comments

[Иван]

затереть я не боюсь, просто интересно почему так как описал выше не сделано в популярных фрейворках? наверно есть какие-то недостатки такого подхода?

[Ramallah]

Иван: все потому, что уровень фреймворков шагнул несколько вперед, углубляясь в абстракции, инкапсуляции и пр... Хотя по сути, логика сводится к такому же методу, просто несколько более навороченному.

Answer 2

[He11ion]

Потому что у Вас а) сильная связанность - когда каждая вьюха должна знать какие поля есть в app и какие ей нужны и б) при увеличении количества обработчиков этого app вы банально не сможете определить какая конкретно функция/класс пишет неверные данные. Используйте на практике принципы ООП, это здорово помогает.

Да, на небольшом проекте из 10 страниц разницы не видно, но если получается что-то большое и/или написанное несколькими людьми - будут проблемы.

Comments

[Иван]

у меня сильная связанность? что вы напутали, как раз у меня слабая связанность ни контроллер, ни модель, не связаны со вьюхой кроме как по её имени. Смотрите, как это сделано в фреймворках: контроллер и модель знают какие переменные нужно передать во вьюху.

1) include_view('product.php');

2) include_view('product.php', array('h1'=>$this->h1, 'name'=>$this->name1 ...));

Как думаете, какой из этих вариантов имеет большую связанность?

пункт б - тоже указан описании вопроса

Не внимательно читали вопрос и описание к нему.

Answer 3

[Никита]

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