Меню
Что нового?

DB:: DataObject (к вопросам об entity-relation layers)

Verk

Guest
Не использовал, но давно мучаюсь этой задачей разделения layer'ов.

DB:: DataObject выглядит вкусно, надо попробоваь в действии.

Есть ли какие другие достойные альтернативы ?
 
Blindman

Blindman

Новичок
Впечатления на первый взгляд неплохие, но ... см. ниже

Для сравнения элементарный пример

PHP: 
    $rating =& new DataObject_Rating;
    $rating->listing = $listingid;
    $rating->ip = $ip;
    if (!$rating->find(true))
    {
      $rating->rating = $rate;
      $rating->insert();
    }
и

PHP: 
    if (!mysql_num_rows(mysql_query("SELECT * FROM rating WHERE listing = $listingid AND ip = '$ip'")))
        mysql_query("INSERT INTO rating SET listing = $listingid , ip = '$ip', rating=$rate");
Лично мне при беглом взгляде проще въехать в смысл кода в первом варианте.

Однако на лучшей читаемости кода (что может быть и немаловажно, но вообще-то является
делом вкуса), достоинства видимо заканчиваются. Возникают трудности например когда
нужно написать сложное условие с несколькими AND и OR.Много гемора со сложными JOIN'ами
(более 2 таблиц). Невозможно сделать UPDATE более одной записи (DELETE - пожалуйста).

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

Screjet

Новичок
Второй "простой" пример не влазит ни в одни ворота:
нет ни приверки ошибок, ни освобождение resouce.
А вот DB-layer это обрабатывает автоматически.
 
Blindman

Blindman

Новичок
нет ни приверки ошибок, ни освобождение resouce.
А вот DB-layer это обрабатывает автоматически.
Нажмите для раскрытия...
Насчет приверки ашипак, писать ее сюда я думаю не имело смысла, само собой разумеется что это не полный код.

Может быть покажешь, где DB_DataObject освобождает resouce? Я что-то не нашел ...
 
fisher

fisher

накатила суть
в-общем сам тоже проглядел бегло, мои впечатления - для нормального проекта не пойдет, но уже хоть что-то (год назад на тему не было просто ничего). успешно "упаковать" нетривиальную ER-модель в объекты DB:: DataObject вряд ли возможно и годится он действительно для относительно простых приложений.
честно говоря, в общем виде задача эта весьма коварна и польза её обманчива. реляционная модель останется ядром большинства проектов надолго как наиболее обоснованная математически. поэтому если мы хотим гибкое и функциональное средство в рамках какого-то языка программирования, то в процессе разработки рано или поздно сталкиваешься с желанием реализовать именно в этом средстве элеменарные реляционные операции. разумеется, в результате огромен риск получить тяжелый и извращенный mapper каких-то структур данных проекта в какой-то SQL и обратно, польза которого сомнительна, если тот же SQL легче написать руками и работать с массивом результатов. с другой стороны многие знают по собственному опыту, что layer (пусть не универсальный, но заточенный под проекты определенного типа) значительно упрощает разработку и поддержку и добавляет масштабируемость для проектов данного типа. так что думать есть над чем :)
 

kuu

Guest
Re: DB:: DataObject (к вопросам об entity-relation layers)

Автор оригинала: fisher
DB:: DataObject - кто-нибудь имел дело с этим пакетом (или ему подобными)?
если да, то какие впечатления?
http://pear.php.net/manual/en/package.database.db-dataobject.php
http://docs.akbkhome.com/akpear/DB_DataObject.html
Нажмите для раскрытия...
я использовал и активно использую. впечатления самые благоприятные, особенно, если учесть, что я, перед тем как открыть для себя DataObject'ы написал очень похожий собственный класс. ;) я от DB_DataObject тащусь!

из минусов:

1. некоторая недоработанность. например, некорректно работает функция count() - приходится замещать своей. кроме того, в PEAR'овской версии наличенствуют откровенные баги: приходится качать CVS'ную (рек. разработчиком) или фиксить руками.

2. скорость PEAR всё-ж таки сжирает, хоть и не сильно. особенно, с join'ами и т.п.

3. необходимость для каждой операции создавать отделный объект. т.е., если ты через него добавил, то искать по нему уже тяжело (нужно сбрасывать значения - для этого писать свою функцию).

но эти минусы с лихвой перекрываются плюсами, о которых писать, мне кажется, смысла нет.

резюме: это круто, используй.
 
fisher

fisher

накатила суть
>>особенно, если учесть, что я, перед тем
>>как открыть для себя DataObject'ы
>>написал очень похожий собственный класс
ты не одинок ;)
>>скорость PEAR всё-ж таки сжирает,
>>хоть и не сильно. особенно, с join'ами и т.п.
pear имхо тут непричем
>>необходимость для каждой операции >>создавать отделный объект
вот это очень неудобно и неправильно идеологически имхо. т.к. основная задача не просто держать данные, а служить посредником. таким образом, то, что умеет правильно составить запрос к базе и достать данные - это одно, а сам объект "сущность" со своими данными - несколько другое.

>>это круто, используй
свое мнение я уже высказал выше. нет смысла переходить на что-то, что не сможет удовлетворить бОльшую часть потребностей для твоего проекта. для несложных проектов - возможно сгодится. а вот сотряпает ли DataObject такой (совсем несложный и довольно стандартный)запрос (два декартова и один outer):

SELECT blabla FROM
a, b, c
WHERE
a.id = b.fk_id AND
какая-то фильтрация ещё AND
b.id = c.fk_id (+)
 

kuu

Guest
Автор оригинала: fisher
(совсем несложный и довольно стандартный)запрос (два декартова и один outer):

SELECT blabla FROM
a, b, c
WHERE
a.id = b.fk_id AND
какая-то фильтрация ещё AND
b.id = c.fk_id (+)
Нажмите для раскрытия...
кажется, да, состряпает, если только ты нормальный links.ini для базы пропишешь. правда, для второй таблицы связь, возможно, придётся прописать руками. даже если пойдут глюки - можно решить проблему расширением класса.

насчёт "сброса": да, это неудобно, однако, во-первых, это даёт кучу плюсов, и, во-вторых, проблема решается написанием одной функции, возвращающей объект в исходное состояние.
 
Войдите или зарегистрируйтесь для ответа.
Сверху