Я вот думаю стоит ли подключать в свою cms класс для работы с базой, например этот https://github.com/indieteq/PHP-MySQL-PDO-Database-Class или не стоит.
Посмотрев на использование этого класса я понял, что в PDO уже есть всё тоже самое, так зачем переписывать его?
Например:
// 1. Read friendly method
$db->bind("id","1");
$db->bind("firstname","John");
$person = $db->query("SELECT * FROM Persons WHERE firstname = :firstname AND id = :id");
тоже самое что и:
$stmt->bindParam(1, $name);
Можете разжевать мне пожалуйста?
Ответ
99% классов для PDO не нужны.
Потому что PDO - уже класс, и чтобы его улучшить, нужно быть очень хорошим программистом. Обычно же писать обертки для PDO берутся криворукие нубы, которые не умеют работать с PDO, не знают азов программирования, и в итоге получают кривого монстра, который приносит больше вреда чем пользы.
Этот класс - как раз пример такого подхода.
он логирует ошибки (чего делать не должен). Ошибками должен заниматься централизованный обработчик.
он пишет в браузер какую-то ересь про лог файл, чего делать не должен вообще никогда. С какой радости посетитель сайта должен что-то там смотреть в лог файле?! Такие надписи - индикатор того, что перед нами нуб, не сделавший ни одного проекта. Иначе бы он понимал, что в браузер пишется информация для посетителя, а не для программиста.
он НЕ "держит соединение", в том смысле что он не гарантирует, что на протяжении скрипта будет использоваться единственное соединение с БД. Как раз наоборот - из примеров видно, что автор предлагает создавать класс каждый раз заново, создавая и новое соединение с БД. В итоге в скрипте будет столько соединений, сколько будет потомков класса CRUD (обычно это десятки).
он дублирует функционал PDO, который автор не осилил изучить, к примеру функция column().
он ломает функционал PDO, добавляя какой-то ад в виде utf8_encode($value); - то есть тупо портит входящие данные.
вместо того, чтобы упростить синтаксис PDO, автор его усложняет. К примеру, PDO поддерживает позиционные плейсхолдеры, которые в большинстве случаев позволяют значительно сократить писанину и не повторять, как второгодник, одно и то же слово по пять раз. Здесь же их использовать невозможно.
не понимая азов программирования, автор совершает классическую ошибку всех нубов: он смешивает в одном классе функционал, работающий как с соединением в целом, так и с отдельным запросом. Чего делать категорически нельзя, а делать надо беря пример с PDO: отдельный объект для соединения и отдельные объекты для каждого запроса. Это единственно правильный подход. Первый же запрос внутри цикла обработки другого запроса поставит этот класс в очень неприятную позу.
Что характерно, предыдущие ораторы, похоже, считают всё это достоинствами.
Вам я порекомендую сначала освоить PDO, и научиться им пользоваться, понять его сильные и слабые стороны. К примеру, как правильно "держать соединение": либо передавать везде переменную с единственным инстансом класса, либо использовать некий сервис, который будет хранить этот инстанс и выдавать его по запросу; как получать данные сразу в нужном формате не прибегая к криворуким поделиям; как правильно работать с ошибками (в общем случае - никак не надо, PHP прекрасно справляется сам).
После этого можно будет либо писать свой класс, либо поискать чужой, но уже такой, который не несет больше вреда, чем пользы.
Либо, как говорилось выше, вместо библиотеки для одной только работы с БД, взять "библиотеку", которая упрощает еще сотню вещей - от разбора входных параметров до отправки писем - фреймфорк. Для этого обязательно прочесть вот эту статью, но учить после неё не Symfony, а Laravel, который на ней базируется.
Комментариев нет:
Отправить комментарий