Насколько оправданно решение с контроллерами-не-классами?

Question

[Александр Гомзяков]

Во многих популярных фреймворках, таких как Zend, Symfony или Yii, да и вообще в php-приложениях с которыми мне приходилось сталкиваться, контроллер представляет собой экземпляр некоторого базового класса. С другой стороны, не реже встречаются решения, где контроллеры работают с объектами среды, помимо которых в классы оборачиваются только модели.



Я понимаю, что система выглядит стройнее когда контроллеры также являются объектами, но, при этом, не вижу ничего страшного в глобальной видимости нескольких объектов среды окружения (роутер, логгер, и т.п). Мнение, что контроллеры, не являющиеся объектами, быстрее или кушают меньше памяти также не противоречит с моей личной интуицией.



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

Answer 1

[Анатолий]

Ничего страшного в этом нет, как и прироста в производительности. создание класса — плевое действие, на много медленней найти и подгрузить файл (а это делается в обоих случаях). Делают с классами в фреймверках больше из-за однотипности (один элемент — один класс и гибкости — функцинал ооп). Если Вам это не нужно, то ничего совершенно не мешает использовать контроллеры как классы.
Но «гибкости — функцинал ооп» — Это обычно нужно.

Answer 2

[rPman]

Ну и что? В моем быдлокоде встречаются 'ужасные' конструкции вида:

function base(){global $base;return $base;}

Какая разница, как получать доступ к фактори? это чисто синтаксический мусор… просто к экземпляру класса без global не обратишься (конечно, можно идеологически красиво пихать его во все объекты… но стоит ли), а у статических полей класса ограничения (методы есть… но в них так же придется обращаться к глобальным объектам)

Comments

[shagguboy]

несоветую засорять глобальную область видимости. в проектах где больше одного человека, имена типа $base очень быстро закончатся.

[jrip]

Зачем оборачивать в функцию? тогда уж можно просто global там где нужно.
А вообще имхо это ужасно, неизвестно где появился экземпляр класса, в каком он сейчас состоянии и т.п.

[rPman]

..в каждом методе писать global??? увольте, вообще сам факт существования global — ужас, но и запрет хранения в статичных переменных класса объектов сложнее строк и чисел тоже ужас, а создание методов на каждый чих — тоже ужас… (это реально, когда половина фактори-класса — описательная структура для доступа к другим объектам и спискам)

Мой быдло-код — просто обход ограничений php.

[weralwolf]

> но и запрет хранения в статичных переменных класса объектов сложнее строк и чисел
Позвольте поинтересоваться о чем это Вы?
О каком запрете и (чуть выше) ограничениях статических полей классов идет речь? Я как-то вполне себе запросто могу хранить в них любые, сколь угодно сложные, структуры и типы данных, включая те же объекты.

[jrip]

Нифига не понял, чем отличается global $base и $base = base()? или base() это у вас метод класса? тогда вообще ничего не понимаю) Да и зачем вообще какие-то глобальные переменные? Ну ок база данных, если напрямую к ней из контроллера обращаемся, а что еще? Имхо у вас проблемы с архитектурой.

[rPman]

Я кажется довольно ясно выразился, что именно необходимость писать global $base меня и не устраивает… ведь эту конструкцию приходится писать не в месте использования переменной, а в начале метода… и это можно забыть сделать (потенциальное место для ошибок).
Да, именно к таким базовым объектам как база данных таким образом я и обращаюсь… в глобальной области видимости у меня обычно 3-4 объекта, не больше… и главное используются они в одном месте (там где описаны их функции) при рефакторинге изменить потребуется только там.

[jrip]

Ну вообще никто не мешает писать в любом месте метода. А так для базы данных тогда уж лучше использовать что-то вроде Singleton, имхо.

[weralwolf]

Или реестр. Всяко лучше global.
Простейший:

class Registry{
    private static $_storage = array();
    public static function get($key){
        return isset(self::$_storage[$key]) ? self::$_storage[$key] : null;
    }

    public static function set($key, $value){
        self::$_storage[$key] = $value;
    }
}

Или и вовсе примитивный, даже без класса:

function registry($key, $value = null){
    static $_storage = array();
    if($value !== null){
        $_storage[$key] = $value;
    }
    return isset($_storage[$key]) ? $_storage[$key] : null;
}

Answer 3

[Иван]

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

Конечно, если проект не настолько сложный, то и вопроса не возникнет )))

Answer 4

[Владимир Чернышев]

В symfony вроде как контроллер вовсе не обязан быть классом. Вернее классом он не может быть в принципе. Может быть методом класса, может быть функций, в общем любым callable.

Если же вообще имеется в виду код глобального неймспейса без какой-либо обёртки (практически «спагетти»-код, только с разделением M и V), то категорически против — сильно затрудняет какое-либо совместное использование, потому что переменные любого контроллера становятся переменными глобального неймспейса.

Comments

[Анатолий]

// my_controller.php
$variable = 5;
// end my_controller.php

// app.php
function startApplication()
{
include 'my_controller.php';
}
// end app.php

// index.php
include 'app.php';
startApplication();
// а теперь угадайте чему равна переменная $variable здесь?
// end index.php

Хватит может уже городить глупостей про засорение глобальной области видимости? Этого можно прекрасно избежать при желании даже без классов. Главное подойти с умом а не городить говнокод. Не важно какой контроллер.

Answer 5

[egorinsk]

В чем преимущество $GLOBALS['router']->… перед App::getRouter()->....?

Второй вариант: 1) позволяет в 1 месте заменить роутер на другой, позволяет писать аккуратный код без глобальных переменных, красивее. У первого варианта преимуществ нет.

По поводу расхода памяти — расход памяти у вас будет, если много классов и создается много экземпляров, а если у вас 1 статический класс App, оверхеда почти нет.

Контроллеры-объекты поддерживают наследование, что бывает удобно. Но вообще, хороший фреймворк позволяет написать код вида:

require_once 'framework-bootstrap.php';
if (!App::TableGateway('People')->add(array('name' => 'John', 'surname' => 'Johanson'), $errors)) {
die( «Error»);
} else {
App::templateEngine()->render('success.html');
}

И оставляет автору выбор, использовать объекты или нет.

По поводу PHP-библиотек и фремворков — не смотрите на них. Среди известных библиотек много абсолютно неадекватных вещей, которые портируют к примеру с Явы, не отдавая отчета что цена объекта/класса в PHP/JAva разная, производительность разная, цикл работы разный. В итоге получаются монстры типа Zend или уродливого порта Hibernate.

Я вообще крайне плохо отношусь к Open-source продуктам на PHP, их пишут как попало, бездумно, и не советую брать с них пример, а думать своей головой.

Логгер вам не нужен — пишите либо App::log(string) либо сразу file_put_contents('', '', FILE_APPEND) — все равно эти логи никто читать не будет.

Comments

[shagguboy]

это до первого падения больше 15 минут.

Answer 6

[deilux]

Явно обозначенный контроллер — это, как уже сказали, возможность использовать наследование и какие-то общие вещи для всего приложения (или раздела сайта) выносить в базовый класс.
А еще это единственный способ обеспечить грамотное переиспользование кода (теоретическое блабла) и возможность этот код вообще хоть как-то тестировать.
Доступ к глобальным вещам резко сужает применимость написанного кода и пространство для манёвра. Если уж делать, то по уму!