最初のステップは、データベースでの作業を容易にする単純なクラスを作成することでした。 コードはそれほど少なくなく、典型的なクエリは基本的に単純化されました。 また、入力パラメーターは自動的に選別されました。 おまけとして、MySQL以外のデータベースのコードを使用できるようになりました（同じインターフェースを持つクラスを作成することにより）。 少なくともほとんどのリクエストを書き換える必要はありません。 コードは次のようになりました。
$ db = 新しい MysqlDb（$サーバー、$ユーザー、$パス、$ db、$プレフィックス）;
$ db-> select （$ key、$ value ）; //おそらく、異なる数のパラメーターを使用する多くのクエリオプションがありました。
while （$ db-> fetch（））{
$ row = $ db-> getRow（）;
...
}
または$ rows = $ db-> getResult（）;
*このソースコードは、 ソースコードハイライターで強調表示されました。
データベースでの作業を簡素化するために、Active Recordの使用を開始しました。 私の決定は他の人にほとんど失われましたが、それで十分でした。 当時、Zend Frameworkが登場したため、そこからいくつかのアイデアが取り入れられました。 クラス自体はPDOを介して動作しました（ただし、php_mysqlを介して動作するためのライブラリも利用できました）。
コード例：
$ db = Cms_Db :: factory（ 'MySQL' ）;
$ db-> connect（$サーバー、$ユーザー、$パス、$ db、$プレフィックス）;
$ element = $ db-> select （ 'id' 、$ id）;
$ element-> name = '新しい名前' ;
$ element-> update（）; *このソースコードは、 ソースコードハイライターで強調表示されました。
このオプションはかなり前から存在していました。 しかし、時間が経つにつれて、彼は逃し始めました。 このクラスは広く開発され、標準クエリを処理するための新しいメソッドが追加されました。 それまでに、Zend Frameworkの安定リリースがリリースされました。 常に新しいタイプのクエリを追加するのは面倒です。
時間が経つにつれて、私はサイトの主要なオブジェクトのモデルを書き始めました。 内部では、私の古いクラスはまだ機能していましたが、外部では、すべての操作はかなり透過的に見えました。 このアプローチが気に入ったため、実装を簡素化するために、ORMを使用することにしました。 最初は、DoctrineとPropelを詳しく調べましたが、最終的に実装を書くことにしました。
データベースの操作はZend_Dbを介して実行されます。柔軟性のために、Zend_Db_Selectも使用されます。 モデルの説明はDoctrineによく似ています。 しかし、私のモデルには、いくつかのデータの表現を記述するためのデータも含まれています。 例を挙げます。
Model_News クラスは Cms_Essence_Modelを拡張します
{
パブリック関数setDefinition（）
{
$ this-> addField（ 'name' 、 'Title' ）
-> addField（ 'link' 、 'Address' 、 'link' ）
-> addField（ 'date' 、 'Post date' 、 'date' ）
-> addField（ 'description' 、 'Short description' 、 'text、255' 、配列（
'validate' => 'isVoid' 、
'detail' => true
）））
-> addField（ 'content' 、 'Content' 、 'editor' 、配列（
'detail' => true 、
'minLength' => 40、
'validate' =>配列（ 'isVoid' 、 'minLength' ））
）））
-> setOption（ 'editorTableClass' 、 'newsTable' ）;
}
}
$ element = Cms_Essence :: get （ 'Model_News' ）-> getById（2）; *このソースコードは、 ソースコードハイライターで強調表示されました。
本格的なORMと同様に、テーブルの関係を記述して、次のようなコードを使用することもできます。
$ user = Cms_Essence :: get （ 'Model_User' ）-> getJoined（ 'Model_Group' 、 'name' 、 'megahertz'）;
$ groupName = $ user-> group-> name; *このソースコードは、 ソースコードハイライターで強調表示されました。
もちろん、そのようなリクエストの便宜のために、私はまだ本格的なORMとは程遠いですが、これまでのところこのオプションは私に合っています。
このアプローチにより、最小限のコードを記述できます。 説明したモデルがあれば、コードを1行も書かずに管理パネルで使用できます。 さらに、管理パネルは、サイト上のクラシック、Ajaxエディター、別のサイト上のRPCなど、任意のタイプにすることができます。 コードを記述しないように、テンプレートでコンポーネントを使用することもできます。 たとえば、Smartyでは、コンポーネントは次のようになります。
{状態モデル= Model_News名=ニュース制限= 3}
< ul >
{= $ニュースからのリスト}
< p >
< b > {$ newsList- > name} {$ newsList- > date} </ b > <br />
{$ newsList- >説明} <br />
<a href = "{$ newsList-> getUrl（）} " >詳細</ a >
</ p >
{/リスト}
*このソースコードは、 ソースコードハイライターで強調表示されました。
このモデルのもう1つの大きな利点は、サンプルの結果を自動的にキャッシュできることです。 選択はすべてキャッシュされ、モデルデータを変更する操作中にキャッシュは自動的にクリアされます。
将来、このアプローチを維持する可能性を排除するのではなく、Doctrineに基づいています。 しかし、そのような必要はありませんが。 これは、抽象化の最後のバージョンとはほど遠いと思います。