Под операциями CRUD вы подразумеваете только (утомительные) запросы к базе данных?
Вы также можете легко настроить базу данных так, чтобы, за исключением нескольких общих полей среди типов контента, все данные для определенного типа контента сохранялись в виде сериализованного ассоциативного массива в поле TEXT.
Таким образом, вам нужен только 1 набор запросов для CRUD любого конкретного типа контента, поскольку данные, передаваемые в функции CRUD, просто слепо сериализуются.
Например, допустим, мы объявляем, что заголовок контента, дата создания / обновления, теги и краткое описание считаются общими данными. Оттуда у нас есть блог и тип содержимого страницы.
Возможно, я бы создал таблицу базы данных следующим образом:
CREATE TABLE `content` (
`id` INT UNSIGNED NOT NULL AUTO_INCREMENT,
`name` VARCHAR NOT NULL,
`short_description` TEXT NOT NULL,
`tags` TEXT ,
`data` TEXT ,
`content_type` INT NOT NULL,
`created_at` DATETIME NOT NULL,
`updated_at` DATETIME NOT NULL,
PRIMARY KEY (`id`)
)
(продолжайте и предположим, что мы создадим справочные таблицы для content_type)
И хотя для блога могут потребоваться данные типа «pingbacks», а странице может потребоваться только тело, вы просто сохраняете вывод чего-то вроде приведенного ниже примера для блога:
$data = serialize(array(
"body" => "Lorem ipsum",
"pingbacks" => array()
));
Обновления выполняются легко, когда вы извлекаете данные из базы данных, вы десериализуете данные для редактирования в форму, выбранную на основе типа контента. Отображение работает таким же образом, просто захватите шаблон на основе типа контента и отправьте ему массив не сериализованных данных. Шаблону не нужно беспокоиться о том, как хранятся данные, просто он получает $ data ['pingbacks'].
Что касается ваших форм, я предлагаю нарушить ваше соглашение об ООП и найти библиотеку генерации форм. Если вы можете извлечь его из фреймворка, используя Zend_Form с Zend_Config и Zend_Validate из Zend Framework (все значения Zend_Config в этом Ситуация с удобным интерфейсом для загрузки и просмотра файлов XML и INI) делает жизнь по-настоящему приятной. Вы можете сделать так, чтобы ваши XML-файлы определяли форму для каждого типа контента, и все, что вам нужно сделать, это просто отобразить форму на своей странице (захват XML на основе типа контента), захват отфильтрованных данных, удаление «общих полей», таких как имя, даты создания / обновления, затем сериализация того, что осталось в базе данных. Знание схемы для определенного типа контента не требуется (если вы не хотите быть строгим).
Хотя, как личность, я бы настоятельно рекомендовал вам изучить Zend_Form (с Zend_Validate и Zend_Config), а также использовать Doctrine в качестве уровня абстракции ORM / базы данных. Возможно, вы обнаружите, что, по крайней мере, Doctrine сделает вашу жизнь намного проще, когда дело доходит до выполнения операций с базой данных.