ZendFramework Шаблон Table Data Gateway. Какие методы можно в него помещать?

  • Автор темы Автор темы seine
  • Дата начала Дата начала

seine

Новичок
Шаблон Table Data Gateway. Какие методы можно в него помещать?

Привет, нужен совет по реализации. Есть объект, который представляет собой таблицу в бд (шаблон Table Data Gateway). Таблица содержит список книг. Из этой таблицы надо получать записи, но не все, а только те, которые подходят по усливиям поиска. Например, чтобы год издания был меньше 1980 и жанр - научная фантастика.
Условия поиска типовые, их не очень много и они должны как бы накладываться на запрос к бд (вообще-то, просто добавляться в секцию "where").
Я сейчас добавил к классу таблицы метод addFilter(), где устанавливаю условие выбора. Вызывать addFilter() можно несколько раз, тогда все условия суммируются. Потом вызывается метод fetchAllUsingFilters() и извлекаются только те поля, которые подходят по заданым условиям.
Кроме метода addFilter() еще есть метод setOrder(), который задает порядок сортировки. Также есть методы, для извлечения записей только с определенной страницы, установки кол-ва записей на одной странице и метод для нахождения общего кол-ва страниц...
А теперь вопрос :-) По-моему, я напихал слишком много методов в класс для работы с таблицей, как я понимаю, этот класс должен быть просто отражением таблицы из бд, а методам для постраничной навигации и фильтрации здесь не место, но тогда где их помещать?
Прошу прощения, за такой тупой вопрос, возможно, я чего-то не понимаю глобального.
Хочется узнать, как это лучше организоват (вплоть до того, как их размещать в файловой системе). Или пошлите меня почитать какой-нибудь паттерн по этой теме или пример из какого-нибудь кода, бо я че-то вообще ниче не пойму.
 
добавить базисы - типа LIMIT, и все что связано с SQL

а все остальные вычесления для пагинации проводить в другом классе, который хавает твой объект таблицы

в ZendFW вроде так...

-~{}~ 04.10.10 17:53:

а вообще пагинация - это вычисления, результаты которых используются в запросе и только
 
добавить базисы - типа LIMIT
можешь подробнее?

как я понял, вынести все, что связано с пагинацией в другой класс, а методы для задания условий выбора и сортировки оставить?
 
У нас такой интерфейс
PHP:
interface IDataMapper {
	function getMetadata();
	function createSearch();
	function find($id);
	function fetch(SearchCriteria $criteria);
	function fetchCount(SearchCriteria $criteria);
	function save(MutableDomainObject $object);
	function delete(ImmutableDomainObject $object);
	function createInstance();
	function toArray(ImmutableDomainObject $object);
	function fromArray(array $row);
	
}

делаем наследника от SearchCriteria и определяем table-specific параметры отбора/сортировки.
 
whirlwind
А как вы извлекаете некий диапазон записей? Т.е. когда надо показать данные только с некоторй страницы (при постраничной навигации)?
 
А как вы извлекаете некий диапазон записей? Т.е. когда надо показать данные только с некоторй страницы (при постраничной навигации)?
SearchCriteria, видать, используют

-~{}~ 04.10.10 16:21:

Я тоже использую похожу схему с критериями, правда у меня они сейчас в виде массива:

PHP:
public function findByParams(array $params=array())
public function findList(array $params=array())

поентому в контроллерах зачастую такие вещи стоят:

PHP:
$params = array
(
    'order' => array($this->getRequest()->getRequest('sort') => $this->getRequest()->getRequest('ad')),
    'limit' => array('start' => $start_limit, 'stop' => $stop_limit),
);

$this->getView()->groups = $this->group_mapper->findList($params);
 
ого, сколько информации) спасибо огромное, буду разбираться)
 
а почему ты метод назвал addFilter? я бы назвал его where.
Не, ну там не просто where, иногда еще должен использоваться join, когда идет выборка по связям многие ко многим (например, выбрать все книги жанра "научная фантастика").
 
join, когда идет выборка по связям многие ко многим (например, выбрать все книги жанра "научная фантастика").
я пришел к выводу, что в подобных шлюзовых решениях подобного рода "фильтры" лучше использовать те, которые относятся к компетенции строки (или в твоем случае таблицы). Т.е. те, которые являются частью простого SQL-запроса. А сложные запросы с join нужно оформлять в виде отдельных запросов/методов.
 
Сверху