Должна ли каждая таблица в Zend сопоставляться с собственным классом?

Question

Я не предлагаю, чтобы все модели были таблицами.

Я спрашиваю, должна ли каждая отдельная таблица иметь свой собственный класс, определенный для нее при использовании Zend? Есть ли способ уйти от этого неудобного кодирования котельной. Мы только начинаем заглядывать в Zend (надеясь оставить процедурный сайт PHP!), И мой коллега считает, что это может закончиться довольно трудоемким временем.

Является ли это причиной для людей, использующих решения ORM? Есть ли другой способ обойти это?

Спасибо за ваши ответы.

Answer 1

Классы Зенд Таблица следуют Table Data Gateway узор, который по определению

... содержит все SQL для доступа к одной таблице или вид: выбор, вставки, обновления и удаления. Другой код вызывает его методы для всего взаимодействия с базой данных.

In the book, Fowler не то, что жесткий об этом, говоря, что

для очень простых случаев, вы можете иметь один TDG, который обрабатывает все методы для всех таблиц. У вас может даже быть один для просмотров или даже для интересных запросов, которые не хранятся в базе данных в виде представлений.

Однако, за исключением использования Просмотров, Zend_Db_Table не подходит для этого. Вы можете создавать запросы к нескольким таблицам, но их нужно будет сделать через Zend_Db_Adapter напрямую или - при использовании объединений - отключив проверку целостности. В противном случае вы должны использовать API, предлагаемый Zend_Db_Table Relationships

Да, один экземпляр должен соответствовать одной таблице или представлению. Вам не нужно создавать классы для этого, если вы не планируете расширять классы. Zend_Db_Table_Definitions позволяют вам настраивать Zend_Db_Table экземпляры на лету.

Обратите внимание, что TDG является архитектурным шаблоном DataSource, а не объектно-реляционным шаблоном. Цель состоит не в том, чтобы помочь с impedance-mismatch, но с разделением кода доступа к базе данных из бизнес-логики.