Помощник
Здравствуйте, гость ( Вход | Регистрация )
Fluent interface (текучий интерфейс) |
Djadka |
2012-04-09, 19:33
Сообщение
#1
|
|
Любитель Группа: Eleanor user Сообщений: 463 Регистрация: 2010-10-17 Репутация: нет Всего: нет |
Интересует вообще все за и против данного подхода в PHP, так же скорость работы и оптимальность? В Элеоноре данный подход не реализован, хотя в некоторых местах был бы очень даже хорош, например в шаблонизаторе.
|
|
|
||
scanread |
2012-04-09, 20:02
Сообщение
#2
|
|
Любитель Группа: Пользователи Сообщений: 227 Регистрация: 2011-07-02 Репутация: нет Всего: нет |
Djadka, а подетальней можно, что это такое и с чем его едят? А то обсуждать то, о чем большинство не слыхало - не имеет смысла... Какие +/- и т.д. и т.п.?
|
|
|
||
Skyff |
2012-04-09, 20:51
Сообщение
#3
|
|
Опытный Группа: Eleanor user Сообщений: 928 Регистрация: 2009-02-08 Из: Литва Репутация: нет Всего: 4 |
Ну да было бы неплохо немного информации получить.
|
|
|
||
Djadka |
2012-04-09, 21:11
Сообщение
#4
|
|
Любитель Группа: Eleanor user Сообщений: 463 Регистрация: 2010-10-17 Репутация: нет Всего: нет |
Википедия
Это общая информация, на данной технологии или подходе реализовано много ORM библиотек да и не только ОРМ. Где что читал и из хабры и ещё были какие то источники, везде мнение расходилось, кто к чему привык, а вот на счёт оптимальности использование и ресурсоёмкости не кто не что не сказал. Вот интересует мнение, кто с чем сталкивался. |
|
|
||
KDesign |
2012-04-09, 23:55
Сообщение
#5
|
|
Любитель Группа: Eleanor user Сообщений: 153 Регистрация: 2009-09-18 Из: Екатеринбург Репутация: нет Всего: нет |
хм..интересно,спасибо! есть повод для размышлений,
похоже,очевидно, что нагрузка будет немного больше, чем в простом ООП. Но, я все же за обычный ООП АПИ ) |
|
|
||
Djadka |
2012-04-10, 0:31
Сообщение
#6
|
|
Любитель Группа: Eleanor user Сообщений: 463 Регистрация: 2010-10-17 Репутация: нет Всего: нет |
Бытует мнение что меньше будет нагрузка... Вот надо бы мнение бывалых.
|
|
|
||
Гость_wizard993_* |
2012-04-10, 17:15
Сообщение
#7
|
|
Гости |
scanread, Основная идея в том, чтобы возможна была такая конструкция:
Для этого должна быть реализована примерно такая архитектура класса:
Чуть по-подробней Тоже удивлялся, почему Александр не использовал Fluent Interface. Если в оригинале написано так:
То с использованием "текучих интерфейсов" было бы примерно так:
Хотя пример довольно неудачный, я думаю, что в некоторых случаях такую технологию было бы удобно использовать. Сообщение отредактировал wizard993 - 2012-04-10, 17:28 |
|
|
||
Djadka |
2012-04-10, 17:59
Сообщение
#8
|
|
Любитель Группа: Eleanor user Сообщений: 463 Регистрация: 2010-10-17 Репутация: нет Всего: нет |
Вот кто то пишет что скорость падает, кто то пишет что наоборот. Вот надо самому будет потестить. А то не понятно вообще.
|
|
|
||
Alexander |
2012-04-11, 5:12
Сообщение
#9
|
|
Eleanor developer Группа: Администраторы Сообщений: 5 261 Регистрация: 2008-11-11 Из: Николаев Версия системы: RC5 Репутация: нет Всего: 67 |
wizard993, я подумаю где в системе такое можно реализовать. Но пока не нахожу таких мест. Ваш пример с шаблонизатором неудачен. Объясняю почему. Каждый метод шаблонизатора возвращает шаблон. Тоесть строку, состояющую из кусочка будущей страницы. Fluent interface хорош для изменения состояния объектов, но при получении данных из них этим методом воспользоваться невозможно. Точнее, можно, но с костылем-финализатором:
Финализатором здесь служил GetHTML, который в результате возвратит не объект. А строку. Хотя нет. Все-же возможен вариант и без финализатора. Нужно будет применить этот подход. Ушел думать. Добавлено через 2 минут, 39 секунд: Djadka, подскажите, где еще можно реализовать данный подход. |
|
|
||
Djadka |
2012-04-11, 7:44
Сообщение
#10
|
|
Любитель Группа: Eleanor user Сообщений: 463 Регистрация: 2010-10-17 Репутация: нет Всего: нет |
Я в ядре сделал, в классе Db, Eleanor::$Db->Query('',array(),0/*Флаг для возврата тела, для того что бы остальные компоненты были не тронутыми*/)->Fetch_assoc. Это дело в некоторых моментах компактнее, вот только вопрос, как на счёт оптимальности скорость и ресурсоёмкость??? Мне сказали что в данном случае если метод возвращает класс, то создаётся временный свой класс, но опять же в скорости в теории есть прирост. Я знаю один фраемворк он весит 70 метров и работает он только на текучки, летает он быстрее молнии, вот только в этом ли фишка.
|
|
|
||
Гость_wizard993_* |
2012-04-11, 12:36
Сообщение
#11
|
|
Гости |
Alexander, согласен, пример крайне неудачный.
Пока не представляю как реализовать без финализатора Я бы написал что-то типа такого:
Пример обращения:
Если есть идеи как избавится от финализатора и/или массива $html, то пожалуйста изложите идею Ну, например, как вариант абстрагирования SQL-запросов. Где-то видел ваш пост, где вы писали о том, что не могли придумать красивую обёртку для SELECT'а Ну так вот: Допустим есть такой запрос:
А в случае Fluent Interface:
Естественно всё это парсится, подставляются апострофы и т.п., но принцип, думаю, понятен. В Zend Framework'е на днях копался, там примерно так и реализуется (В версии 1.11: \ZendFramework-1.11.11\library\Zend\Db\Select.php) P.S. Тут пришло озарение В варианте без использования финализатора подразумевается шаманство с __toString() ? Сообщение отредактировал wizard993 - 2012-04-11, 13:20 |
|
|
||
Alexander |
2012-04-11, 16:44
Сообщение
#12
|
|
Eleanor developer Группа: Администраторы Сообщений: 5 261 Регистрация: 2008-11-11 Из: Николаев Версия системы: RC5 Репутация: нет Всего: 67 |
Зачем? Там уже и так все было реализовано. Query возвращает объект Result, который без дополнительных плясок имеет метод fetch_assoc() и fetch_row(); Мой опыт говорит о том, что абстрагировать SELECT запросы чаще всего невозможно. Хотя этим занимаются даже разработчики IPB. Но результат блевотный. Абстрагировать можно лишь простейшие запросы, но в этом случае смысл абстрагирования для меня теряется. Попробуйте абстрагировать запрос со сложной выборкой, статическими данными в результатах, вложенном запрос (не JOIN). Интересно, как это получится? Я даже с трудом понимаю, как можно абстрагировать UPDATE запросы, когда изменяется не одна таблица, а несколько... Даже если вам и удастся абстрагировать такие запросы, я почти уверен, что к вашему подходу придется написать не одну страницу документации. Что затрудняет понимание и отбивает желание новичков. Плюс из абстракции не всегда понятно, что хотел ею добиться автор. Именно. Но там еще есть пару пикантных моментов. Напишите мне на мыло - если удастся реализовать все, как я хочу - скину вам тест версию системы с реализованным Fluent interface. |
|
|
||
Djadka |
2012-04-11, 18:48
Сообщение
#13
|
|
Любитель Группа: Eleanor user Сообщений: 463 Регистрация: 2010-10-17 Репутация: нет Всего: нет |
Вот было бы интересно сравнить скорость и ресурсоёмкость с текучкой.
|
|
|
||
Гость_wizard993_* |
2012-04-11, 19:16
Сообщение
#14
|
|
Гости |
Мой опыт говорит о том, что абстрагировать SELECT запросы чаще всего невозможно. Хотя этим занимаются даже разработчики IPB. Но результат блевотный. Абстрагировать можно лишь простейшие запросы, но в этом случае смысл абстрагирования для меня теряется. Попробуйте абстрагировать запрос со сложной выборкой, статическими данными в результатах, вложенном запрос (не JOIN). Интересно, как это получится? Я даже с трудом понимаю, как можно абстрагировать UPDATE запросы, когда изменяется не одна таблица, а несколько... Даже если вам и удастся абстрагировать такие запросы, я почти уверен, что к вашему подходу придется написать не одну страницу документации. Что затрудняет понимание и отбивает желание новичков. Плюс из абстракции не всегда понятно, что хотел ею добиться автор. Который раз уже говорю спасибо за разъяснения. С радостью посмотрю. Напишу в пятницу. У вас, наверное, пока и так забот хватает. А пятница уже как бы разгрузочный день. Djadka, постараюсь покапать интернет на недельке, если что интересное найду - отпишусь постом. Сообщение отредактировал wizard993 - 2012-04-11, 19:21 |
|
|
||
Alexander |
2012-04-12, 2:47
Сообщение
#15
|
|
Eleanor developer Группа: Администраторы Сообщений: 5 261 Регистрация: 2008-11-11 Из: Николаев Версия системы: RC5 Репутация: нет Всего: 67 |
wizard993, все реализовал механизм по своей задумке. Стало жрать чуть меньше памяти. Кода стало так же меньше. Посмотрите потом
|
|
|
||
Гость_wizard993_* |
2012-04-12, 7:06
Сообщение
#16
|
|
Гости |
Alexander, написал на мыло
|
|
|
||
Djadka |
2012-04-12, 13:17
Сообщение
#17
|
|
Любитель Группа: Eleanor user Сообщений: 463 Регистрация: 2010-10-17 Репутация: нет Всего: нет |
А как на счёт скорость работы? Стало шустрее или нет?
|
|
|
||
Alexander |
2012-04-12, 18:18
Сообщение
#18
|
|
Eleanor developer Группа: Администраторы Сообщений: 5 261 Регистрация: 2008-11-11 Из: Николаев Версия системы: RC5 Репутация: нет Всего: 67 |
Djadka, миллисекунды не сравниваю. По-моему так же.
Добавлено через 0 минут, 19 секунд: Могу дать архив - сами сравните. До и после. |
|
|
||
Текстовая версия | 0.0364 сек. 11 запросов GZIP включен Сейчас: 2024-04-24, 14:30 |