製品、注文など、いくつかのオブジェクトがあります。データベースから情報を取得すると、行を取得してオブジェクトのタイプの 1 つを作成します。次に、作成したオブジェクトを操作します。私はこれが工場と呼ばれていると読みました。
これを行う利点はありますか？特に、PHP のような緩く型付けされた言語では?
ありがとう
編集:これはデータベースにとらわれない場所ですか? これは、ORM が本質的に行うことですか?
1071 次
2 に答える
1
データベース クエリからオブジェクトを作成することで、オブジェクトとリレーショナル データベース間のマッピングを定義します。これは、まさに ORM ソフトウェアが行うことです。
そうすることで、オブジェクトがデータベースに直接アクセスするのではなく、代わりにデータベース アクセス関数/オブジェクトを使用するようにすることで、次の 2 つの方法でコードを変更から保護します。
データベース スキーマへの変更がコードに波及することはありません。代わりに、コードの変更はデータベース アクセス オブジェクトにのみ配置されます。
元の DBMS と同じインターフェイスに従う新しいデータベース レイヤーを実装することで、別の DBMS に切り替えることができます。他のオブジェクトを変更する必要はありません。
その意味では、データベースに依存しない部分が得られると思いますが、おそらく、そのままでその非依存性を提供するデータベース ライブラリを使用する方がよいでしょう。
私の意見では、利点は、オブジェクトを操作して、オブジェクト指向言語が提供するすべての利点を得られることです。その後、データベース クエリをふるいにかけることなく、(定義したオブジェクトに関して) より高いレベルでドメイン ロジックを読み取ることができます。ORM を自分で作成するのは難しい場合がありますが、それを支援するツールが世の中にあります。
これは私が通常取るルートですが、私は PHP 開発をまったく行っていないため、その言語にどの程度適用できるかはわかりません。
于 2010-09-27T22:28:52.133 に答える
0
あなたが説明しているのは、データ アクセス レイヤーの実装です。Factory Method パターンやAbstract Factory パターンの例のようには聞こえません。
はい、ORM はオブジェクトからリレーショナル データベースへのギャップを埋め、データ アクセス レイヤーとして機能します。使用するORMには、特定の長所/短所/制限があることに注意してください。経験と要件によっては、独自のデータ アクセス レイヤーを作成することをお勧めします。サードパーティの ORM を使用する必要があるとは思わないでください。
はい、優れたデータ アクセス レイヤーを使用すると、ビジネス ロジック、UI、またはその他のコードを変更することなく、ストレージ メカニズム (異なるデータベース、XML、フラット ファイルなど) を簡単に交換できます。
緩い型付け言語または強い型付け言語に関係なく、OO 言語で作業している場合は、データ オブジェクト (ORM または独自のデータ アクセス層によって提供される) を使用してコードを記述する方がはるかに簡単です。ビジネス層がデータベースと直接連携する、データ アクセス層のないシステムを作成することは可能だと確信しています。ただし、実装と維持はより困難になる可能性があります。
于 2010-09-28T14:36:02.140 に答える