Comments 13
Хм. А разве префикс имен классов "Zend" не зарезервирован разработчиками?
может быть и так, но используя Zend_Loader хочется придерживаться общего вида
В таком случае, как вариант, можно было бы создать рядом с директорией Zend свою, назвать ее, например, OmeZ, запихнуть обе в директорию library и записать путь к последней в include_path. Тогда Zend_Loader будет работать и с именами OmeZ_ActiveRecord. Т.е. по названному классическим макетом в соответствующей статье.
Я лишними обвесами
if (!isset($this)) return self::get_instance()->find($options);
не пользуюсь, а к псевдостатитке обращаюсь так:
Вместо:
$post_instance = new Post();
$post_instance->find();
*****
Post::getInstance()->find();
if (!isset($this)) return self::get_instance()->find($options);
не пользуюсь, а к псевдостатитке обращаюсь так:
Вместо:
$post_instance = new Post();
$post_instance->find();
*****
Post::getInstance()->find();
да, я согласен, но есть несколько нюансов почему именно так: в вызовах мы намерянно используем статичный вызов, потому как де-факто он и должен быть статичным, стопором являются лишь ограничения языка. В дальнейшем это дает гибкую расширяемость и миграцию по версиям. К примеру выйдет наконец 5.3 версия PHP, Post::getInstance()->find() будет уже не кстати. Обвязка на то и обвязка, что делается ориентация на дальнейшее развитие компоненты без реструктуризации остального кода. Post::find() таким и останется везде.
Да причем такая форма вызова красивей, да и работать будет быстрее кстати. Я точно не знаю почему, вроде делается один лишний вызов функции, но я проверил по бенчу, и там мой метод выдал на 7% большую производительность чем вариант Post::getInstance()->find()
Да причем такая форма вызова красивей, да и работать будет быстрее кстати. Я точно не знаю почему, вроде делается один лишний вызов функции, но я проверил по бенчу, и там мой метод выдал на 7% большую производительность чем вариант Post::getInstance()->find()
Не знаю откуда там взялось 7% плюса. Post::getInstance()->find() на одну операцию меньше выполняет:
(!isset($this)) не исполняется, а isset на неопределенных переменных медленней всего работает.
А с 5.3 всё равно переписывать прийдётся (Только любителям чистого кода). В первом случае убирать в модели обвес, во втором случае в Контроллере. Где быстрее зависит от приложения. Правда в большинстве случаев Модель переписывать быстрее.
(!isset($this)) не исполняется, а isset на неопределенных переменных медленней всего работает.
А с 5.3 всё равно переписывать прийдётся (Только любителям чистого кода). В первом случае убирать в модели обвес, во втором случае в Контроллере. Где быстрее зависит от приложения. Правда в большинстве случаев Модель переписывать быстрее.
я тоже не знаю откуда 7%, но факт. Бенч делался на 10.000 итераций по обоим методам. Хотя по большому счету эти операции не так уж часто будут встречаться, т.к. find() делается один раз на запрос, все связанные модели выдираются через генераторы ассоциаций на более низком уровне. А вместе с php-акселлераторами этот вопрос вообще отпадает.
ну, с 5.3 переписать только несколько базовых функций в модели и это все что потребуется, а в контроллерах капаться это намного дольше, да и все равно в модель лезть придется в любом случае.
ЗЫ. "чистый код - залог психического здоровья"
ну, с 5.3 переписать только несколько базовых функций в модели и это все что потребуется, а в контроллерах капаться это намного дольше, да и все равно в модель лезть придется в любом случае.
ЗЫ. "чистый код - залог психического здоровья"
да, и чуть не забыл, вызов как статичной функции дает возможность впоследствии использовать паттерн ActiveHandler для моделей, что тоже дает свои плюсы
Гугль на слова ActiveHandler pattern PHP, чушь выдаёт.
В чом соль этого паттерна?
В чом соль этого паттерна?
ActiveHandler - это обыкновенный handler для ORM. может он еще как-то по другому называется, но я знаком с этим названием еще со старых версий ROR. Суть в том что существует 2 разных класса, один используется для "готового" объекта, другой для обработки еще не существующего, либо в роли "посредника" между данными и процедурной частью. Управление происходит назначением getters и setters. Например у есть уже загруженая из базы запись Post:
$post = new Post(1);
но для нее не определено свойство $post->comments, т.к. я еще не загружал эту связь и также не указал ее для автоматической загрузки. Тем более по факту это должен быть массив, исходя из типа звязи has_many (one-to-many relationship).
Допустим мне надо сделать поиск всех комментариев для ЭТОГО поста с каким-нибудь условием. в стиле rails это выглядит так
$post->comments->find(array('all','conditions'=>......));
так вот Handler и выполняет эти операции на уровне класса Comment а не Post, тем самым упрощая логику вызова. В рельсах для этого есть динамическая перегрузка методов массива (в руби все есть объект, даже массивы и числа - это все объекты), в пхп для этого я использую handler, а в качестве управляющих структур - методы __get и __set
$post = new Post(1);
но для нее не определено свойство $post->comments, т.к. я еще не загружал эту связь и также не указал ее для автоматической загрузки. Тем более по факту это должен быть массив, исходя из типа звязи has_many (one-to-many relationship).
Допустим мне надо сделать поиск всех комментариев для ЭТОГО поста с каким-нибудь условием. в стиле rails это выглядит так
$post->comments->find(array('all','conditions'=>......));
так вот Handler и выполняет эти операции на уровне класса Comment а не Post, тем самым упрощая логику вызова. В рельсах для этого есть динамическая перегрузка методов массива (в руби все есть объект, даже массивы и числа - это все объекты), в пхп для этого я использую handler, а в качестве управляющих структур - методы __get и __set
Sign up to leave a comment.
использование псевдостатических методов на примере Zend_Db_ActiveRecord