Forum Webscript.Ru
Программирование => PHP => Тема начата: Aku Aku от 10 Апреля 2004, 12:40:26
-
стандартная бекофисная задача:
есть список записей, к ним нужно приделать фильтр (+ORDER, +GROUP BY) а также постраничную разбивку.
Первое что приходит в голову это создать обьект Filter который будет уметь себя отображать, а также добавлять условия, примерно так:
$filter = new Filter();
$filter->addCondition($fieldName, $string, $conditionType);
//@param conditionType: like, startWith, greater, ... etc.
...
$fiter->addOrder($fieldName, ORDER_TYPE);
...
$filter->setLimit($from, $to);
и сохранять этот обьект например в сессии (не суть важно где)
потом использовать его в SQL запросе:
$query = "SELECT id, name, email FROM users " . $filter->getConditions() . $filter->getOrders() . $filter->getLimit();
тут бы и взяться за работу, но:
1) есть сомнения что такие фокусы пройдут с более сложными запросами (с JOIN-нами например)
2) как то не очень елегантно смотрится второй блок кода :-)
Сейчас размышляю над таким вариантом:
сделать mapping обьекта (того который извлекается запросом, в данном случае User). Все условия и ограничения добавлять в XML-ю модель, а потом генерить SQL запрос.
Что думаете, бредовая идея? К тому же не могу найти никакого PHP инструмента (класса) для маппинга, кто знает подскажите - если даже для данной задачи его не применю, все равно пригодится.
-
я бы отослал тебя к соответствующим наблам на dklab.ru
в пятом пхп, кстати, как Котеров утверждает, есть плэйсхолдеры
-
что-то похожее реализовано в pear::DB::DataObject
посмотри
-
кстати почитай про паттерн DAO на phppatterns.com и на форуме
http://www.sitepoint.com/forums/forumdisplay.php?f=147 (там одно время этот паттерн очень часто обсуждался)
-
а о какой БД идет речь? если не о MySQL, а скажем MS SQL то стоит смотреть в сторону процедур, ф-ций и тригеров
-
AliMamed
вообще-то это ООП фреймворк, костяк уже есть, теперь пишу специфеские классы для бекофиса. Но первый проект который сразу же на нем делается, именно на MySQL. А там посмотрим...
Макс
да пересмотрел весь PEAR, вообще как раз DataObject то и заинтересовал, но он не укладывается в логику фреймворка.
Я вообще отказался от создания обьектов типа например UserItem, ArticleItem, etc. с которыми работает DataObject. У меня на все сущности есть один класс FormBean который содержит в себе массив обьектов Field. И для каждой сущности (User, Article, News)
есть XML mapping такого типа:
value=""
type="hidden" />
value=""
title="Username"
tip="Enter valid username"
type="text"
required="true"
varType="string"
maxLength="20" />
...
такая структура мне кажется более гибкой. Ну а там время покажет :-)
За линк спасибо, почитаю.
RomikChef
да, либа интересная. кстати в pear::db я также нашел плейсхолдеры:
http://pear.php.net/manual/en/package.database.db.intro-execute.php (http://pear.php.net/manual/en/package.database.db.intro-execute.php)
только не уточняется, применима ли эта фича к MySQL, нужно будет попробовать.
2 All
еще линк по теме (с phpbuilder.com):
A Practical Approach to Object-Relational Mapping in PHP (http://www.phpbuilder.com/columns/mathieson20040309.php3?page=1)
тоже интересный подход, актуальный при наличии большого числа наследуемых обьектов.
Христос воскрес!
-
я в свое время тоже решал похожую проблему и все-таки решил делать через наследование.
Например.
Допустим есть две сущности - "новость" и "пользователь".
Действия, которые производятся с новостями - выборка/добавление/редактирование/удаление
А вот действия, которые могут произведены с пользователем -
активация аккаунта, авторизация, выход, "вспомнить пароль" (+то что и с новостями).
Если делать как у тебя, то либо в базовом классе надо предусмотреть методы для всевозможных действий и класс быстро разрастется либо базовый класс будет делать лишь базовые действия (добавление/редактирование/удаление) и всю остальную логику работы с сущностью реализовывать "вручную" (то есть вне класса).
Оба эти метода мне кажутся кривыми.
-
Все таки выборка/добавление/редактирование/удаление это самые стандартные действия над обьектом. Пример с аутентификацией это скорее исключение. Но у меня, в рамках архитектуры, нету обязательного базового класса. Она вкратце такова:
Есть контейнеры, которые могут содержать модули (и другие контейнеры). Грубо говоря количество контейнеров равно количеству пунктов меню. Каждый контейнер и модуль имеют свой шаблон. Вся инфа о том какие модули входят в контейнер прописывается в XML конфиге. Модуль должен обязательно наследовать AbstractModule (кроме прочего, поставляет модулю обьекты шаблонизатора, БД, текущий контекст) и реализовывать один метод: String render(), т.е. возвращать свой View в контейнер. Других ограничений нету, т.е. можно создавать любые иерархии классов внутри модуля, или модуль просто может читать статический файл и возвращать его.
брр.. разошелся :-)
короче говоря, если интересно - могу выслать когда до ума доведу.