CRUD操作とは、(面倒な)データベースクエリだけを意味しますか?
コンテンツ タイプ間でいくつかの共通フィールドを除いて、特定のコンテンツ タイプのすべてのデータがシリアル化された連想配列として TEXT フィールドに格納されるように、データベースを簡単にセットアップすることもできます。
この方法では、CRUD 関数に渡されたデータが盲目的にシリアル化されるだけなので、特定のコンテンツ タイプを CRUD するために必要なクエリのセットは 1 つだけです。
たとえば、コンテンツのタイトル、作成/更新日、タグ、および短い説明を共通データと見なすことを宣言するとします。そこから、ブログとページのコンテンツ タイプがあります。
データベーステーブルを次のように作成する可能性があります。
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'] を取得するだけで、データの保存方法を気にする必要はありません。
フォームに関しては、反 OOP 規約を破り、フォーム生成ライブラリを見つけることをお勧めします。フレームワークから抽出できる場合は、Zend フレームワークのZend_ConfigおよびZend_ValidateでZend_Formを使用します。(この状況での Zend_Config はすべて、XML および INI ファイルを読み込んでトラバースするための便利なインターフェイスです) 生活を本当に快適にします。XML ファイルに各コンテンツ タイプのフォームを定義させることができます。ページにフォームをレンダリングし (コンテンツ タイプに基づいて XML を取得)、フィルター処理されたデータを取得し、次のような「共通フィールド」を削除するだけです。名前、作成日/更新日、残っているものをデータベースにシリアル化します。特定のコンテンツ タイプのスキーマに関する知識は必要ありません (厳密にしたい場合を除きます)。
個人的なことはさておき、Zend_Form (Zend_Validate と Zend_Config を使用) を取得し、Doctrineを ORM/データベース抽象化レイヤーとして使用することを検討することを強くお勧めします。少なくとも Doctrine を使用すると、データベースで操作を実行する際の作業が非常に簡単になることに気付くかもしれません。