Comments 48
Для элементарных запросов абстракция подходит, а вот для сложных... Можно глянуть код mysql класса IP.Board. На мой взгял, это ООП ради ООП (я иею ввиду имеено mysql модуль). Хотя, возможно, для безопасности это плюс.
Хм, по-моему в первом коде это "классы и методы ради ООП", хотя это, конечно, не ООП. А вот последний код, имхо, показывает удобство ООП в грамотных руках.
Насчет последнего: смысл делать ООП, если можно стандартной функцией превратить мускульную строку в массив? Т.е. получится что-то вроде:
{list from=$news}
{$newsList['name']} {$newsList['date']}
{$newsList['description']}
подробнее
{/list}
{list from=$news}
{$newsList['name']} {$newsList['date']}
{$newsList['description']}
подробнее
{/list}
В PHP массивы похожи на объекты, по сути - и то и то - хэш-таблицы(очень условно отбрасывая многие навески объектов). Но вот как их использовать - в первом случае вроде используются объекты, но если посмотреть - код чисто процедурный. Дело не в инструментах, дело в идее:)
Таки отвечая на ваш ответ "смысл?". Да, можно было взять массив, урл брать из какой-нибудь функции... Вроде проблем нет, кроме вмешательства в глобальную область видимости. Кстати, для смарти пришлось бы писать хелпер, в общем, плюсов у этого подхода в данном случае всё-таки больше, имхо.
Таки отвечая на ваш ответ "смысл?". Да, можно было взять массив, урл брать из какой-нибудь функции... Вроде проблем нет, кроме вмешательства в глобальную область видимости. Кстати, для смарти пришлось бы писать хелпер, в общем, плюсов у этого подхода в данном случае всё-таки больше, имхо.
Это не совсем массив. В модели можно переопределить возвращаемое значение любого поля, написав метод get<Имя поля="поля">. К тому же, компонент автоматом преобразует значение из БД в строковое (к примеру, timestamp в человекопонятный вид), опираясь на тип поля.
Я оставил возможность использовать модель в обычных запросах через Zend_Db_Select. К примеру
$model = Cms_Essence::get('Model_News');
$model->select()->limit(10, 20);
$elements = $model->execute();
$model = Cms_Essence::get('Model_News');
$model->select()->limit(10, 20);
$elements = $model->execute();
Эволюция описана наглядно:) От процедурного подхода до действительно ООП:)
Если не секрет, сколько между первым и последним кодами в годах/месяцах?
Если не секрет, сколько между первым и последним кодами в годах/месяцах?
UFO just landed and posted this here
Необязательно. Абстракция - ключ к масштабируемости:)
А после этого чудного флешбека придет понимание, что смысла дергать каждый раз базу данных - вообщем-то и нету, многое можно просто закэшировать.
А менять удобство и скорость разработки на написание десятка тыщ строк кода, который сложен в поддержке... думаю прикупить еще один сервер - будет самым разумным решением.
А менять удобство и скорость разработки на написание десятка тыщ строк кода, который сложен в поддержке... думаю прикупить еще один сервер - будет самым разумным решением.
а чем плох mysqli? у нас в коде враппер для БД построен именно как потомок mysqli класса, с переопределением функций для добавления нужного функционала. Тормозов на частых запросах к БД нет, хотя система используется весьма напряжённо.
Если не ошибаюсь в
"
$bd = Cms_Db::factory('MySQL');
$db->connect($server, $user, $pass, $db, $prefix);
$element = $db->select('id', $id);
$element->name = 'New name';
$element->update();
"
Перепутал $bd с $db
Мелочь, но все же)
"
$bd = Cms_Db::factory('MySQL');
$db->connect($server, $user, $pass, $db, $prefix);
$element = $db->select('id', $id);
$element->name = 'New name';
$element->update();
"
Перепутал $bd с $db
Мелочь, но все же)
А мне лично кажется паттерн DataMapper более удобным нежели различные реализации ORM, все-таки у каждого СУБД есть свои специфичные особенности, которые в общем ORM'е все учесть сложно, и DataMapper в этом плане предоставляет большие возможности для использования сложных, составленных вручную запросов с учетом специфики СУБД. При переходе на другой СУБД DataMapper конечно придется переписывать, но я лично считаю это оправданным, в мелких проектах это не так много работы, а в крупных не так часто меняют СУБД, и там как раз таки очень важна производительность. Ну и при необходимости использования нескольких вариантов хранения информации - DataMapper можно инстанциировать через фабрику.
Тут есть готовый лисапед phpdoctrine.org, кто нить пользовался?
Да. Кривой, глючный и неудобный. Но лучше всех других таких лисапедов, правда.
Из лисапедов в PHP мне нравится Propel - классная вещь
Я на дух не переношу оарэмы, в которых сначала надо описать структуру во внешнем файле, а потом на этой базе создаются PHP-классы. Я неправ?
Ну например использую hibernate можно писать все в одном файле с классами - аннотациями завется, правдо к php это не имеет небольшое отношение, видно жавакодеры тоже не навидили разнесение всего по отдельным файлам :)
Я использовал DBDesigner, его XML через XSLT в нужный пропелу формат конвертил. Все автоматизированно - за секунду изменения из DBDesigner накатывались на классы пропела, оказалось очень удобно. Структуру описываешь в ERM диаграмме.
ORM имеет большой минус, я не видел ни одного который бы нормально работал со сложными джоинами.
ЗЫ: Кстати если знаете, подсуньте ссылку.
ЗЫ: Кстати если знаете, подсуньте ссылку.
А потом придет осознание что весь сложный код для работы с БД, надо хранить в самой БД.
И из приложения просто его вызывать.
И из приложения просто его вызывать.
Такие задачи не так часто встречаются и под них обычно нет смысла писать универсальные решения
Не так часто, это от области работы сильно зависит.
Я только с такими и работаю.
Получается что для простейших действий, например, взять строку - показать, обновить то что ввел юзер. Это проще делать через объектную модель.
А вот сформировать отчет, загрузить/выгрузить данные во внешний источник, рассчитать нечто. Это все делается через хранимые процедуры и никак иначе. Главное вовремя разобраться что и как делать лучше.
Я только с такими и работаю.
Получается что для простейших действий, например, взять строку - показать, обновить то что ввел юзер. Это проще делать через объектную модель.
А вот сформировать отчет, загрузить/выгрузить данные во внешний источник, рассчитать нечто. Это все делается через хранимые процедуры и никак иначе. Главное вовремя разобраться что и как делать лучше.
UFO just landed and posted this here
я так смотрю в итоге ORM получилась...а почему б пропел не взять сразу?
А Вы используете bind_variables и умеете-ли регулировать fetch_size ?
Если нет, то Вы отходите от масштабирования совершенно в другую сторону. :(
Если нет, то Вы отходите от масштабирования совершенно в другую сторону. :(
Вдумчиво читаем весь тред и, особенно, статью про объектно-реляционное отображение.
чёрт его знает, но мне всегда хватало $db = new mysqli(...);
Не знаю, как вам, а мне больше нравится, когда я сам, ЛИЧНО, пишу тело запроса и отправляю его на выполнение.
$this->db->execute('select user_id from users');
Мне кажется так намного понятней выглядит код в моделях и можно сразу, практически мгновенно найти нужный запрос в коде.
$this->db->execute('select user_id from users');
Мне кажется так намного понятней выглядит код в моделях и можно сразу, практически мгновенно найти нужный запрос в коде.
Зато у Вас никакой абстракции от БД нет и если синтаксис запросов поменяется в связи с переездом mysql на что-то другое, то и будете в моделях править ВСЕ ЗАПРОСЫ.
А вам часто надо на проекте менять субд? :)
Может быть у меня слишком мало опыта - но у меня не было такого случая ни разу в жизни. И думаю, что в общем случае будет максимум 5-10% таких проектов, на которых надо менять СУБД.
Может быть у меня слишком мало опыта - но у меня не было такого случая ни разу в жизни. И думаю, что в общем случае будет максимум 5-10% таких проектов, на которых надо менять СУБД.
врядли надо будет менять в проекте, тут Вы правы.
НО быстрее будет использовать некую абстракцию, которая в новых проектах на НОВОЙ СУБД позволит Вам без труда включиться в процесс разработки. В общем я хочу сказать, что во всякого рода фреймворках абстракция необходима
НО быстрее будет использовать некую абстракцию, которая в новых проектах на НОВОЙ СУБД позволит Вам без труда включиться в процесс разработки. В общем я хочу сказать, что во всякого рода фреймворках абстракция необходима
Присоединяюсь, лично мне всегда хватало DbSimple, по моему очень удобный и быстрый класс для работы с БД. И абстракцию, имхо в реальной жизни практически не востребованную (кроме универсальных фреймворков), предоставляет, и позволяет и полностью контролировать запросы и данные в безопасном виде позволяет вставлять / получать, и кешировать умеет нативно, чего еще надо, никогда не понимал.
С нетерпением жду PHP5.3 stable, что бы пощупать обновленный MySQLi…
С нетерпением жду PHP5.3 stable, что бы пощупать обновленный MySQLi…
А ещё лучше (имхо) выглядит код
Dim userIDs = From u in db.Users Select u.user_id
И о вечных SQL injection'ах, которые постоянно находятся в кое-каком софте, можно забыть.
Dim userIDs = From u in db.Users Select u.user_id
И о вечных SQL injection'ах, которые постоянно находятся в кое-каком софте, можно забыть.
Чего только люди не выделывают. Лишь бы делать вид, что LINQ2SQL не существует.
Sign up to leave a comment.
Абстракция БД