Xpoint
   [напомнить пароль]

БД - интерфейсы

Метки: [без меток]
[удл]
2004-05-24 14:36:19 [обр] Евгений(0/8)[досье]
Недавно прочитал статью о построении БД-интерфейсов, которые являются надстройкой над классом абстракции типа AdoDB (хотя, применение класса абстракции и не обязательно, просто я подчеркнул, что говорю не об обычном абстрактном классе). Суть в том, что создается по одному интерфейсу-классу для каждой таблицы, используемой в скрипте. И эти классы содержат методы типа get(), submit() (выполняющий функции INSERT-UPDATE) и другие, что практически устраняет необходимость применять в скриптах SQL-запросы.
Вопрос такой: можете ли Вы поделиться опытом использования таких классов(если используете) и вообще насколько данный подход целесообразен? Есть ли какие-либо рекомендации по построению подобных интерфейсов? Какие-либо нюансы, приемы? Я не говорю об ООП вообще, а конкретно по реализации данных классов работы с таблицами. Заранее спасибо.
спустя 48 минут [обр] Максим Деркачев(7/568)[досье]
не в тот раздел
спустя 28 минут [обр] Евгений Бондарев aka Eugene Bond(31/1600)[досье]
М Перенесено из форума "Программирование::PHP"
спустя 9 минут [обр] Андрей Новиков(16/1242)[досье]
Какой-то вопрос очень общий. Да, используем. Да, круто. Очень целесообразен. Нюансов реализации не заметили, всё диктуется общей архитектурой системы.
спустя 2 часа 57 минут [обр] Сергей Сирик(28/737)[досье]

А потом в каком-то из проектов необходима стурктура со сложными связками между таблицами, и фреймворки всякие начинают жутко мешать. Сейчас как раз озабочены тем, что "выживаем" из проектов один такой фреймворк. ИМХО (и не только Му:) - современные языки и так достаточно навороченные и высокоуровневые, чтоб на них еще какие-то надстройки придумывать.

P.S. вышесказанное откносится к ASP.NET, который все-таки по наличию и навороченности работы с БД чуть поболе РНРы будет, при всей моей любви к последней :)

А применительно к РНР - не сильно ли расточительно с точки зрения ресурсов будет?? На какждую табличку класс заводить ...

спустя 1 час 9 минут [обр] Андрей Новиков(16/1242)[досье]
Что есть "сложные связки"?
спустя 10 минут [обр] Евгений(0/8)[досье]
Сергей Сирик[досье]
Дело ведь не в навороченности, а в желании максимально упростить управление кодом и снизить возможность ошибок.
По поводу расточительности - все зависит от количества табличек, можно заводить классы только для самых используемых табличек. Кстати, можно ведь и вообще сделать один класс под весь проект для всех таблиц сразу, разные решения могут быть.
А вот по поводу изменения проекта (насколько я понял) и связей между таблицами... Может надо планировать так, чтобы любые эти изменения минимально сказывались на интерфейсе? И тогда наоборот, изменения придется проводить в основном во фреймворках, а не в коде? У меня пока немного опыта, я скорее спрашиваю, чем предлагаю, пытаюсь анализировать.
спустя 32 минуты [обр] Евгений(0/8)[досье]
Сергей Сирик[досье]
Как же все-таки быть когда используются выборки из нескольких таблиц одновременно? Может вообще не работать в коде приложения на уровне полей таблиц и просто создать интерфейс для нужных операций?А внутри этого класса вытворять все, что угодно на SQL.
спустя 4 часа 22 минуты [обр] Дмитрий Попов(6/509)[досье]

Сергей Сирик[досье]
Фреймворк фреймворку рознь.

А поповоду классов - нет ничего плохого, что бы на уровень абстракции выбрать те действия, которые в Web встречаются в 90% случаев - простая выборка из одной таблицы, выборка из двух таблиц, левостороння выборка из двух таблиц, вставка в одну таблицу и апдейт одной таблицы.
Но, конечно, нельзя лишать возможности и просто делать обычные запросы...

спустя 16 часов [обр] Сергей Сирик(28/737)[досье]

Связки - JOINы на несколько таблиц ... Например когда многие-ко-многим реализовывается. В основном хотелось сказать, что фреймворк - это далеко не панацея :)

Про расточительность неправильно написал, сорри :(( Имелось ввиду инициализировать объект для каждой таблички. Т.е. место того, чтоб выполнить запрос и получить результат, надо сначала выполнить не самую быструю операцию инциализации объекта, а только потом выполнить запрос. А перед этим еще надо и файл с описанием класса проинклюдить ...

спустя 3 дня [обр] Мистик(7/13)[досье]

Имхо, в PHP такой подход не очень целесообразен. Большинство Web-приложений уступают по функционалности Desktop-приложениям, посему не требуют слишком частых обращений к БД. Проще напрямую использовать SQL.

Среди интересных реализаций БД-интерфейсов есть в Cache'

спустя 2 дня 17 часов [обр] Максим Деркачев(7/568)[досье]

Мистик[досье]

Имхо, в PHP такой подход не очень целесообразен. Большинство Web-приложений уступают по функционалности Desktop-приложениям, посему не требуют слишком частых обращений к БД. Проще напрямую использовать SQL.

Видимо, у вас большой опыт в написании большинства Web-приложений.

Powered by POEM™ Engine Copyright © 2002-2005