Версия для печати темы Нажмите сюда для просмотра этой темы в оригинальном формате

Форум программистов > PHP: Общие вопросы > PHP работа с базой через объекты

Автор: Atlete 7.7.2008, 11:17

Вот задался я таким вопросом, в java для работы с базой есть интересный фреймворк hibernate и еще один ibatis (те с которыми я сталкивался). А вот теперь суть вопроса, если какой либо аналог для PHP чтобы работать с базой на уровне объектов или же необходимо самому написать свое решение?

Автор: Sannis 7.7.2008, 11:33

Есть. Doctrine, Propel, остальные есть http://en.wikipedia.org/wiki/List_of_object-relational_mapping_software#PHP.

Автор: Atlete 7.7.2008, 11:41

Огромное спасибо, буду изучать

Автор: Mal Hack 7.7.2008, 11:57

А чем не устраивает стандартное средство PHP - PDO? http://php.net/pdo

Автор: Feldmarschall 7.7.2008, 12:01

Почитай по ссылке Sannis - чем.

Автор: Mal Hack 7.7.2008, 12:08

и? Нужны низкоуровневые исходники?

Автор: Sannis 7.7.2008, 14:41

Нужно объектное предствление таблиц, т.е. не ОО интерфейс к БД как таковой, а ORM обёртка, насколько я понимаю.

Автор: Mal Hack 7.7.2008, 16:19

А можно банальный тупой пример, как это выглядит...

Автор: Pokoinik 7.7.2008, 16:27

Mal Hack,  Код <?php class User extends Doctrine_Record {     public function setTableDefinition()     {         // set 'user' table columns, note that         // id column is auto-created as no primary key is specified         $this->hasColumn('name', 'string',30);         $this->hasColumn('username', 'string',20);         $this->hasColumn('password', 'string',16);     }     public function setUp()     {         $this->actAs('Timestampable');     } } ?> http://www.phpdoctrine.org/documentation/manual/0_11?one-page

Автор: Mal Hack 7.7.2008, 16:41

Обычная ООП обертка, с большей абстракцией...  Лишнее... ИМХО.

Автор: Pokoinik 7.7.2008, 17:49

Mal Hack, согласен Единственное приемущество - более красивый код (эстетическое наслаждение . Приятно, мапишь в XML колонки БД на поля объектов, и просто пользуешь объекты. Из недостатков выяснилось: 1. Отвратительный перфоманс. Иногда нужно прочитать просто поле объекта, а ORM инициализирует все поля и зависимые сушности, хоторые нах. не нужны в данный момент 2. От ORM ожидаешь что кода будет меньше. Получается наоборот. 3. Усложняется отладка. Вместо понятного отточеного SQL exception получаешь stacktrace ошибок внутри движка ORM 4. Дополнительные уровни абстракции нужны, чтобы скрывать детали реализации, чтобы не приходилось вникать в то, что подложено снизу. На практике хватает дырок в абстракциях, из-за которых пока не разберёшь весь нижний уровень - не поймёшь что сверху происходит.  5. SQL заменитель (внутренний язак запросов) вместо реального SQL иногда сильно ограничивает возможности

Автор: Mal Hack 7.7.2008, 18:31

Ну а чего вы хотите? Первая надстройка - переопределенный и расширенный класс PDO или MySQL, вторая - API самой библиотеки...

Автор: sTa1kEr 7.7.2008, 19:23

Цитата(Okoinik @  7.7.2008,  18:49 ) Единственное приемущество - более красивый код (эстетическое наслаждение smile. Это вообще не преимущество.  Имхо, преимущества ORM заключаются в: Увеличение скорость разработки. И это не только за счет генерации готового кода на основании уже спроектированных схем UML, YAML, etc, либо высокого уровня абстракции (хороший пример Zend Framework, где для создания модели объекта, достаточно прописать одно свойство), но и самой работы с этими сущностями. Такая технология сильно упрощает создание хорошо масштабируемых систем. Расширение функционала адаптера. Хороший пример - это iBATIS. Их шаблонная реализация SQL запросов добавляет еще один уровень абстракции, что дает достаточно интересные перспективы. Представьте prepared statements, которыми можно описать достаточно сложный динамический запрос и с одинаковым синтаксисом для всех БД. Хотя именно к ORM это уже имеет не большое отношение... Цитата(Okoinik @  7.7.2008,  18:49 ) Отвратительный перфоманс. Да, это так. Но при грамотном подходе его можно компенсировать. Цитата(Okoinik @  7.7.2008,  18:49 ) Иногда нужно прочитать просто поле объекта, а ORM инициализирует все поля и зависимые сушности, хоторые нах. не нужны в данный момент Если нужно только прочитать поле - то  нужно просто прочитать поле. Зачем использовать ORM там где это не нужно? Для эстетики кода? Цитата(Okoinik @  7.7.2008,  18:49 ) Усложняется отладка. Вместо понятного отточеного SQL exception получаешь stacktrace ошибок внутри движка ORM Если получаешь stacktrace ошибок движка, то может стоит использовать более удачную реализацию движка, с обработкой ошибок? Цитата(Okoinik @  7.7.2008,  18:49 ) На практике хватает дырок в абстракциях, из-за которых пока не разберёшь весь нижний уровень - не поймёшь что сверху происходит.  То же что и предыдущий пункт.

Автор: nerezus 8.7.2008, 06:56

Mal Hack, а как насчет автоматической генерации админки? как насчет простого save() вместо написания запросов? как насчет отсутствия лишнего кода по преобразованию объекта в запрос для записи в базу и кода по преобразованию результатов запроса в объекты при выборке?

Автор: Mal Hack 8.7.2008, 09:40

Цитата(nerezus @  8.7.2008,  06:56 ) Mal Hack, а как насчет автоматической генерации админки? как ты себе это представляешь? Давай просто определимся с термнами чтоли, а то мне кажется мы несколько о разных вещах говорим. Цитата(nerezus @  8.7.2008,  06:56 ) как насчет простого save() вместо написания запросов? Против. Абстракция - хорошая вещь, но в меру. Для каждой задачи есть какой-то максимальный уроень абстракции, который нельзя превышать, иначе теряется управляемость скрипта. Цитата(nerezus @  8.7.2008,  06:56 ) как насчет отсутствия лишнего кода по преобразованию объекта в запрос для записи в базу и кода по преобразованию результатов запроса в объекты при выборке?  Я могу и в массивы преобразовать, что будет куда более оптимальнее. Код-то не лишний, ты просто его не видишь =)

Powered by Invision Power Board (http://www.invisionboard.com)
© Invision Power Services (http://www.invisionpower.com)