オブジェクト工場の質問 - データベースクエリ情報を使用してオブジェクトを作成する

Question

製品や注文などのいくつかのオブジェクトがあります。データベースから情報を取得すると、連続してオブジェクトの種類の1つを作成します。次に、作成されたオブジェクトを使用して作業します。これは工場と呼ばれています。

これを行うことにはいくつかの利点がありますか？特にPHPのような緩やかに型付けられた言語で？

ありがとう

編集：これはデータベースのagnosticityを取得する場所ですか？これは本質的にORMですか？

Answer 1

データベースクエリからオブジェクトを作成することにより、オブジェクトとリレーショナルデータベースの間のマッピングを定義します。これはまさにORMソフトウェアが行うことです。

そうすることで、オブジェクトがデータベースに直接アクセスしないようにすることにより、代わりにデータベースアクセス関数/オブジェクトを使用することにより、2つの方法でコードを保護しています。

• データベーススキーマの変更は、コードを介して波及しません。代わりに、コードの変更は、データベースアクセスオブジェクトにのみ配置されます。

• オリジナルと同じインターフェイスに従う新しいデータベースレイヤーを実装することにより、別のDBMSに切り替えることができます。他のオブジェクトは変更を必要としません。

その意味では、データベースと存在感を得ることができますが、おそらくその概要を提供するデータベースライブラリを使用する方が良いでしょう。

私の意見では、利点は、オブジェクトを使用して、オブジェクト指向の言語が提供するすべての利点を獲得していることです。その後、データベースクエリをふるいにかけずに、ドメインロジックをより高いレベルで（定義したオブジェクトの観点から）読み取ることができます。自分でORMを書くのは難しいかもしれませんが、それを助けるツールがあります。

これは私が通常取るルートですが、私はPHP開発をしていないので、それがその言語にどれほど適用されるかは言えません。

Answer 2

あなたが説明しているのは、データアクセスレイヤーの実装です - それは ファクトリーメソッドパターン, 、 抽象的な工場パターン.

はい、ORMSはオブジェクトからリレーショナルデータベースへのギャップを埋め、データアクセスレイヤーとして機能します。使用するORMには、特定の長所/短所/制限があります。経験と要件に応じて、独自のデータアクセスレイヤーを書くことは良い考えです。サードパーティのORMを使用する必要があると感じないでください。

はい、優れたデータアクセスレイヤーにより、ビジネスロジック、UI、またはその他のコードを変更せずに、ストレージメカニズム（異なるデータベース、XML、フラットファイルなど）を簡単に交換できます。

ゆるい型または強い型の言語に関係なく、OO言語で作業している場合、データオブジェクトを使用してコードを作成する方がはるかに簡単になります（ORMまたは自家製のデータアクセスレイヤーによって提供）。ビジネスレイヤーがデータベースで直接動作するデータアクセスレイヤーのないシステムを作成することが可能だと確信しています。しかし、実装と維持がより困難になる可能性があります。