Зачем 100 запросов? Можно обойтись одним.
Каждый элемент коллекции наследует от абстрактного родителя метод
Entity_Abstract::setFromArray(array $data) где $data — ассоциативный массив.
Collection реализует метод Collection::findById(int $id) при вызове которого результат выборки сохраняется во внутреннем хранилище.
При попытке получения элемента коллекции вначале проверяется наличие объекта во внутреннем кеше, если он не создан — создается.
Если очень хочется, можно объединить.
Скажем, реализовать коллекцию с использованием ArrayAccess, данные хранить в виде ассоциативного массива, при запросе отдельного элемента — проверять, есть ли он в кэше объектов коллекции, если есть — отдавать из кэша, если нет — создавать объект, ложить в кэш и отдавать.
Боюсь только, что узким местом здесь будет расход памяти на больших коллекциях, хотя большие выборки из базы — повод пересмотреть архитектуру.
А почему не создавать самому классы коллекций? Или использовать кодегенератор.
Ваша реализация имеет зависимость от класса Collection, от которой лучше избавиться.
Метод Collection::__check_type(&$object) реализован неверно: вы либо возвращаете true, либо кидаете exception. По логике, вы должны либо кидать exception и возвращать void, либо возвращать true|false без exception. Про то, что объекты передаются по ссылке, уже писали.
Кодинг стандарта вообще нет.
Возможно я придираюсь, но код оформлен не очень красиво. Для такого простого примера можно было бы и постараться.
даа, у mail.ru самооценка зашкаливает
интерестно, этот чел только в интернете, такой наглый?
а вообще, есть хорошая поговорка — наглый, как пидар, ну, вы поняли…
Ну что за идиотизм! Не являюсь фанатом CakePHP, однако:
1. Не было проблем с порогом вхождения, так как вначале прочел документацию.
2. После прочтения доков было понятно где что лежит и что заменять.
3. В CakePHP не требуется наличие базы и модели для контроллера — в доках написано, как отключить в своих экземплярах контроллеров.
4. График с АРС показывает более чем двухкратное превосходство YII — и это «тяжело утверждать об преимуществе в скорости».
Этих примеров хватило, чтобы поставить под сомнение ценность статьи для меня.
а бывает и так, что верстальщик тег Label не использует, и программист вставляет его сам
а бывает и так, что потом за свое самовольство программист получает по шапке от менеджера
я, в общем-то, и имел ввиду дерево с ветками, и да, я сделал такое, но не на досуге, а по долгу службы, и не заглядывая в интернет, особо сложного я тут не вижу ничего
еще раз хочу сказать, это не «низкий уровень», а руки кривые (или в случае с вашей библиотекой — нежелание рефакторить код)
«низкий уровень» — это, например, использование «чистого js» безо всяких фреймворков, а «низкоуровневых тегов» не бывает
кстати, никто не мешает использовать серверный контрол, который может генерировать наш «прекрасный высокоуровневый список»
Каждый элемент коллекции наследует от абстрактного родителя метод
Entity_Abstract::setFromArray(array $data) где $data — ассоциативный массив.
Collection реализует метод Collection::findById(int $id) при вызове которого результат выборки сохраняется во внутреннем хранилище.
При попытке получения элемента коллекции вначале проверяется наличие объекта во внутреннем кеше, если он не создан — создается.
Скажем, реализовать коллекцию с использованием ArrayAccess, данные хранить в виде ассоциативного массива, при запросе отдельного элемента — проверять, есть ли он в кэше объектов коллекции, если есть — отдавать из кэша, если нет — создавать объект, ложить в кэш и отдавать.
Боюсь только, что узким местом здесь будет расход памяти на больших коллекциях, хотя большие выборки из базы — повод пересмотреть архитектуру.
и используем CollectionFactory::Create()
как это понять?
Ваша реализация имеет зависимость от класса Collection, от которой лучше избавиться.
Метод Collection::__check_type(&$object) реализован неверно: вы либо возвращаете true, либо кидаете exception. По логике, вы должны либо кидать exception и возвращать void, либо возвращать true|false без exception. Про то, что объекты передаются по ссылке, уже писали.
Кодинг стандарта вообще нет.
Возможно я придираюсь, но код оформлен не очень красиво. Для такого простого примера можно было бы и постараться.
так что рано смеялись
интерестно, этот чел только в интернете, такой наглый?
а вообще, есть хорошая поговорка — наглый, как пидар, ну, вы поняли…
1. Не было проблем с порогом вхождения, так как вначале прочел документацию.
2. После прочтения доков было понятно где что лежит и что заменять.
3. В CakePHP не требуется наличие базы и модели для контроллера — в доках написано, как отключить в своих экземплярах контроллеров.
4. График с АРС показывает более чем двухкратное превосходство YII — и это «тяжело утверждать об преимуществе в скорости».
Этих примеров хватило, чтобы поставить под сомнение ценность статьи для меня.
а бывает и так, что потом за свое самовольство программист получает по шапке от менеджера
еще раз хочу сказать, это не «низкий уровень», а руки кривые (или в случае с вашей библиотекой — нежелание рефакторить код)
«низкий уровень» — это, например, использование «чистого js» безо всяких фреймворков, а «низкоуровневых тегов» не бывает
кстати, никто не мешает использовать серверный контрол, который может генерировать наш «прекрасный высокоуровневый список»