以下にリストされているルックアップテーブルがいくつかあります。私の理解では、データベーステーブルごとにモデルが必要ですが、これはルックアップ/マッピングテーブルにも当てはまりますか？モデルの作成中に使用されるベストプラクティスは何ですか？以下は私のルックアップテーブルのサンプルです...
Transaction Customer Transaction_Lookup
id Id transection_id
date name customer_id
active active
TransactionテーブルとCustomerテーブルに対応するモデルを作成しましたが、Transaction_Lookupにも対応するモデルを作成する必要がありますか？
また、データマッパーパターンを使用しています。つまり、モデルごとにマッパークラスを作成する必要があります...
よろしくお願いします。
私が言うことの1つは、モデルをテーブルと1対1で対応しているとは考えないことです。これは、OOP設計を非常に制限する可能性があります。とはいえ、モデルが1つのテーブルに整列することがよくあります。ルックアップテーブルは、これが当てはまる明らかなシナリオです。
ルックアップテーブルごとに具体的なモデルが必要な場合は...「ルックアップ」テーブルに対応するすべてのオブジェクトに使用できる汎用モデルを作成することを検討します。次に、そのジェネリッククラスを使用するか、抽象クラスとして記述して拡張し、名前付きの具象クラスを作成できます。そこに必要な一意のコードの量は、親クラスにすでにあるものを利用して、非常に制限される可能性があります。ルックアップテーブル固有の抽象が必要な場合は、フィールドkey（id）、value、friendly name、activeを抽象化できますか？テーブルの対応するフィールドをそれらの一般的なプロパティにマップします。それについては本当にいくつかの方法があります。私がそれをうまく説明したことを願っています。
私は通常、2つのスタイルのマッパーを作成します。1つは本質的にZend_Db_Tableのようなテーブル行ゲートウェイであり、もう1つはよりカスタムであり、おそらくストアドプロシージャまたは複数のテーブルを結合する複雑なZend_Db_selectsを使用します。テーブル行ゲートウェイスタイルのマッパーを使用する場合、通常、マッパーが機能するテーブル名、アダプター、およびマップされたオブジェクトを指定する必要があります。カスタムマッパーでは、通常、ケースバイケースで実装コードを最初から作成する必要があります。
私はデータマッパーを使用するこのアプローチが好きです。便利で強力です。