ソフトウェア エンジニアリングにおいて、アクティブ レコード パターンはアーキテクチャ パターンです。リレーショナル データベースのメモリ内オブジェクト データを格納するソフトウェアで使用されます。2003 年にMartin Fowlerが著書「Patterns of Enterprise Application Architecture」でこのパターンに命名しました。[1] [2]このパターンに準拠するオブジェクトのインターフェイスには、挿入、更新、削除などの機能に加えて、基になるデータベース テーブルの列にほぼ直接対応するプロパティが含まれます。
アクティブ レコード パターンは、データベース内のデータにアクセスするためのアプローチです。データベース テーブルまたはビューはクラスにラップされます。したがって、オブジェクトインスタンスはテーブル内の 1 つの行に関連付けられます。オブジェクトの作成後、保存時に新しい行がテーブルに追加されます。ロードされたオブジェクトは、データベースから情報を取得します。オブジェクトが更新されると、テーブル内の対応する行も更新されます。ラッパー クラスは、テーブルまたはビュー内の各列の アクセサー メソッドまたはプロパティを実装します。
このパターンは、オブジェクト永続化ツールやオブジェクト リレーショナル マッピング(ORM)でよく使用されます。通常、外部キー関係は、プロパティを介して適切なタイプのオブジェクト インスタンスとして公開されます。
実装
この概念の実装は、多くのプログラミング環境のさまざまなフレームワークで見つけることができます。たとえば、partsデータベースに列name(文字列型) とprice(数値型) を持つテーブルがあり、クラスにアクティブレコードパターンが実装されている場合Part、擬似コード
part = new Part () part . name = "サンプル部品" part . price = 123 . 45 part . save ()
指定された値を持つテーブルに新しい行を作成します。これはSQLコマンド
partsとほぼ同じです。
INSERT INTO parts ( name , price ) VALUES ( 'Sample part' , 123 . 45 );
逆に、このクラスを使用してデータベースをクエリすることもできます。
b =パーツ.find_first ( " name" 、"gearbox" )
これにより、列の値が「gearbox」であるテーブルPartの最初の一致する行に基づいて新しいオブジェクトが検索されます。使用される SQL コマンドは、データベースの SQL 実装の詳細に応じて、次のようになります。
partsname
SELECT * FROM parts WHERE name = 'gearbox' LIMIT 1 ; -- MySQL または PostgreSQL
批判
大きなファイル
データとデータベース アクセス メソッドは同じファイル内にあるため、これらのファイルは大きくなります。
単一責任原則と関心の分離
アクティブ レコード パターンに対するもう 1 つの批判は、データベース インタラクションとアプリケーション ロジックの強い結合により、アクティブ レコード オブジェクトが単一責任の原則と関心の分離に従っていないというものです。これは、これらのプラクティスに適切に対処する多層アーキテクチャとは対照的です。[引用が必要] [説明が必要]このため、アクティブ レコード パターンは、 CRUD機能を備えたフォーム オーバー データである単純なアプリケーション、またはアーキテクチャの一部としてのみ使用されるのが最適であり、最も頻繁に使用されます。 [引用が必要]通常、その部分はデータ アクセスであり、いくつかの ORM がアクティブ レコード パターンを実装する理由です。
参照
- ビジネスオブジェクト – 多層ソフトウェアアプリケーション内のエンティティ
- CRUD – コンピュータデータベースの基本操作
- データマッパーパターン
- オブジェクトリレーショナルマッピング – プログラミングテクニック
参考文献
- ^ EAA カタログの P - アクティブ レコード
- ^ Fowler, Martin (2003). エンタープライズアプリケーションアーキテクチャのパターン. Addison-Wesley. ISBN 978-0-321-12742-6。
