PHP в стиле Delphi VCL

Написав десяток проектов на LAMP пришел к выводу, что при всей гибкости PHP код не дает прорачности и простоты понимания.

посему написал небольшую обертку по мотивам организации этого дела в VCL

Итого вышло 4 класса
1. DBException - для генерации исключений
2. db - абстаркный класс предок
3. db_mySQL - потомок от db с реализацией методов для mySQL
4. dataset - класс управления набором записей.

Код подключение к базе

Eai объясни чем твоя обертка лучше DbSimple, MDB2 или PDO?

И заодно чем оно всё лучше стандартных функций mysql_*?
Можно просто кодом.

-----
PostgreSQL DBA

не знаю, потому как эти библиотеки не нашел

P.S.
Специаьно и написал так что бы носом тыкать начали
(Добавление)


Стандартные функции плохо вписываются в ОО модель и код на них получается не прозрачный. Можно и с ними (собственно говоря долго жил и так) но копаться в котде потом сложнее.
Почему на дельфях прямые выовы не испольуются?
Почему вообще необходимо использовать ООП?
Кроме того такая структура поволяет сделать код портабельным между различными SQL серверами
(Добавление)

PDO - что то надо ставить, не камельфо, не везде стоит
DbSimple - интересно, нашел бы раньше испольовал бы, но все же это стиль PHP а не ООП
MDB2 - опять же надо что то инстаировать , не каждый хостер согласиться

Тут кстати на DbSimple написали

Чем неудобны другие библиотеки
* PEAR DB, ADOdb: библиотеки не упрощают работу с СУБД, они просто предоставляют единый (и многословный) интерфейс; отладочные возможности в зачаточном состоянии.
* PDO: требует PHP 5; неудобная работа с placeholder-ами и результатами выборки.
* Стандартные функции PHP для работы с СУБД: низкая читабельность кода, значительные неудобства в отладке, подверженность уязвимостям вида SQL Injection.

(Отредактировано автором: 06 Ноября, 2009 - 14:36:30)

В вашем коде я вижу лишь только псевдонимы стандартных функций. При том столь отчётливые псевдонимы, что возникает вопрос: а в чём разница?


Вот только разве что. Но, это надо учитывать уже на этапе создания запросов.


Необходимо? Ни в коем случае не необходимость. Использовать нужно только наиболее подходящие методы.


Не знаю, меня объектный паскаль, а тем более де-факто только виндовый, не интересует.

-----
PostgreSQL DBA

Вот кусок кода от DBSimle

Я ничего не имею против ООП, наоборот, считаю, что штука полезная, особенно в области разделения видимости и взаимодействия объектов (в том числе с единым интерфейсом и иерархическими описаниями наследований).
Например, относительно GD, ImageMagick весьма удобный класс. Хотя бы тем, что тип файла распознает самостоятельно
Но всё на ООП делать - не стоит. А то может echo надо в класс воткнуть и запретить вывод?


Ну потому и пишу "де-факто" ;) В далёком 2002 (когда выпустили под линуха делфю) году у меня не то, что линуха не стояло, вообще ПК не было


Не очень... Зачем писать кучу кода, который ещё и выполняться будет, отнимая ресурсы, для достаточно постоянной СУБД?


Вот, примерно это и спрашивал. Если отдавать заботиться о экранировании и проверке данных на корректность единожды написанному методу, то это уже неплохой повод использовать такие классы. Правда, если они при этом не потребляют ресурсов в пару раз больше всего скрипта
А то по первому сообщению данной возможности не было видно.

И по самому классу:
Я так понимаю, что конструктор инициализирует соединение с БД по дефолтным значениям, определённым в классе?
А $db->set_params($dbhost, $dbname, $dbuser, $dbpasswd, "utf8"); - просто возможность сделать коннект к другой базе? А почему бы не передавать эти данные сразу конструктору, чтобы класс не создавал дважды соединение?
Почему бы закрытие соединения не вынести в метод __destruct? Тогда будет закрываться самостоятельно. (или я плохо понимаю, когда этот метод вызывается?)
Выбор БД я бы определил тоже по-умолчанию, т.к. в рамках 1 проекта БД меняется не слишком часто и в крайнем можно обратиться к ней по полному имени - т.е. база.таблица.имя_поля

-----
PostgreSQL DBA

Опять же потому что СУБД может меняться и ГЛАВНОЕ для прозрачности кода и его четкой структуры


А знаете сколько с тех пор именилось Достаточно постоянные быза мхом порасли



Ну я же не писал и то что dataset может иметь наседников, а это реально воможно.


Вообще по уму нужно 2 конструктора, пустой и с параметрами, но к сожалению PHP это не поддерживает. Создайте наседника который имел тот конструктор который вам нужен

Про деструктор, может быть вы и правы, но нужно иметь "насильный" метод тоже
Баа.таблица - плохой вариант, потому что не таблица а запрос!
Кроме того это нарушает принцип абстракции, апрос независит от БД

P.S.
Извиняюсь за орфографию, клавиатура умирает потихоньку

(Отредактировано автором: 06 Ноября, 2009 - 16:32:19)

А значения по-умолчанию для чего ещё даны? Это-то как раз не сложно сделать.


Это не спорю, нужно. Можно даже его же в деструкторе и вызывать. Это просто к тому, что пускай класс сам закрывает соединение, раз уж его можно этому научить


Да, это не самый верный вариант, но, в некоторых случаях единственный возможный. А в случае класса, реализующего соединение с БД, наоборот, указание БД по-умолчанию, такое же логичное действие, как и указание пользователя, хоста, пароля соединения. Или же, нелогичное, т.к. тогда не видно, куда коннектится и под чьим именем скрипт. Может он под рутовым пользователем сидит в базе?


А ведь всё равно надо будет шерстить скрипты при изменении имени БД, хоть для указания set_db($db);, хоть для запросов.
Либо, аналогично, тянуть переменную с именем вторичной БД и вставлять это имя в запросы через обычную конкатенацию.

-----
PostgreSQL DBA

Это совсем не одно и тоже


Как это под рутовым, кто его пустил то туда
База по умолчанию нужна, в 90% она еинственная.
По уму в ООП реализуется статическое свойство класса.
В PHP я думаю нужно реалиовать глобальную функцию currentDB().


Ну батенька, я про абстракцию иное имел ввиду.
Вот вы содали класс который занимается форматирование вывода, ему скормили dataset (или наследника) и даже не паритесь что а БД. А то что если у вас что то кардинально меняется то код менять придется .. от ентого ничего не избавит

Поясните, почему не сделать например так:

-----
PostgreSQL DBA

Eai, там дата 2006-03-03. Т.е. прошло уже 3.5 года.
Сейчас PHP5 это стандарт.
На счёт не удобной работы placeholder-ами и результатами выборки, то это просто мнение.
Имхо, как раз в этом плане в PDO очень даже удобная штука.

Если дело только в объектно-ориентированном стиле, то это поддерживается практически всеми известными библиотеками для работы с БД, включая MySQLi.


Погляди здесь, найдешь пару сотен подобных.

[quote=Ch_chov]

Спасибо

По-моему, штука удобная для использования в своих проектах. А для массы - очередной велосипед. Я вот вобще не понимаю, зачем работу с БД делать в ООП. Коннект вынес в отдельный файлик и всё. А все эти обертки на выполнение запросов не нужны совсем.