где инстанция класса на каждый результат? здесь вся тема пока в основном сводится к байтодрочу, свичодрочу и ифодрочу. аргументы Придёт Мр.Мит и скажет - нафига столько классов. Исключения ему уже не понравились.
PHP: 55. if ($fetch == 'irow') { 56. return new goDBResultRow($result); 57. } 58. if ($fetch == 'iassoc') { 59. return new goDBResultAssoc($result); 60. } 61. if ($fetch == 'icol') { 62. return new goDBResultCol($result); 63. } 64. if ($fetch == 'iobject') { 65. return new goDBResultObject($result); 66. } то есть ты сам не знаешь чем плох синглтон?
Это итераторы, которые могут использоваться наравне с обычными массивами, в некоторых случаях. Злоупотреблять ими не нужно. http://pyha.ru/go/godb/fetch/
сучке, мне на работе уж нужно было 30 минут назад быть) плох тем, что привязывает нас к конкретной реализации класса, плохо тестируется. гг, http://pyha.ru/forum/topic/4820.0
ах, да, да, несвязность, инверсия зависимостей... ещё юнит-тесты на всё и подробный UML. и пых сменить на яву. это прекрасно, но в большинстве случаев используется только частично. причём, среди тех людей с которыми работал, те, кто больше всего говорили о подобном прекрасном, писали совершенно противоположный код. godb позволяет хранить подключения у себя. Если хотите для хранения использовать синглтоны/мультитоны, вам не нужно делать своё. Не хотите, хотите IoC и т.п, godb вам в этом ничуть не мешает, не используйте её хранилища.
это я знаю, что гоДБ умеет по-всякому. Просто можно выкинуть добрый пласт кода или хотя бы переместить его в отдельный класс мы еще вам покажем кузькину мать
godb 1.2.2 Одно из важнейших нововведений - наконец то использованый свичи вместо ифов в одном из методов. Это увеличило удобство использования неимоверно.
метод query умеет слишком много. сделай так чтобы он возвращал result object у которого уже будут методы для получения данных в нужном виде
tenshi Я бы не возвращал сразу. Оставил бы внутри класса, и возвращал уже fetch. IPB etc. PHP: <?php $this->DB->select(array('select' => '*', 'from' => 'tab' )); while($res = $this->DB->fetch()) { //some code }
PHP: <? $table= $this->db->query( 'select * from [tab]' )->row_list var_dump( $table ); // repl foreach( $table as $num => $row ): //some code endforeach;
Чем это будет отличаться, от стандартного поведения, где mysqli возвращает объект, который требуется потом обрабатывать? Или даже от mysql_query(), которая возвращает ресурс и его также приходится пропускать через mysql_fetch_* и подобное? admyx, о вашем предложении сказано в FAQ, п.2.
vasa_c Способ используемый mysqli в возвращением объекта универсален и может быть реализован для всех прочих драйверов. Плюс в том, что не происходит лишнего перебора данных и перезаписывание их в другую переменную. А если данных много? Получится out of memory.
Если данных много (весьма редкий случай в веб-приложениях), для этого предусмотрены итераторы + возможность получения тогоже mysqli_result. В большинстве случаев, перебор данных всё же происходит, только производится вручную программистом после запроса.
я тоже скажу, что у меня, например, юзается возврат для запросов типа SELECT объекта результата, но я почти всегда извлекаю либо одну запись, либо все, причем в той же строчке абстракции, что и выполнение запроса, поэтому немного солидарен с vasa_c
> Чем это будет отличаться, от стандартного поведения, где mysqli возвращает объект, который требуется потом обрабатывать? а должно пренепременно отличаться? > Или даже от mysql_query(), которая возвращает ресурс и его также приходится пропускать через mysql_fetch_* и подобное? хочешь услышать лекцию о том чем ооп отличается от процедурщины?
Мне не нравится каждый раз выполнять монтонный однообразные действия, поэтому для меня должно отличаться. Это основное предназначение большинства библиотек - упрощение однообразных действий. При этом я осознаю, что лично для вас удобнее по-другому и ниразу ничего не навязываю. Спасибо, лично от вас я этих лекций здесь наслушался, не хочу.