3

PHP、特に WordPress プラグインでは、人々が SQL をプラグインに直接記述しているのをよく見かけます... 私が学んだ方法では、すべてをレイヤーで処理する必要があります... そのため、ある日、特定のレイヤーの要件が変更された場合、すべてがインターフェースするレイヤーを変更することだけを心配する必要があります。

現在、データベースとやり取りする方法に何か変更があった場合に、作成した X 個のプラグインではなく、1 つのレイヤーを変更するだけでよいように、データベースとインターフェイスするレイヤーを作成しています。

これは他の人が過去に遭遇した可能性があることであり、私のアプローチは非効率的であると感じています.

私は次のようなクラスを書いています

Table
Column
Row

これにより、すべての機能を処理する特定のメソッドを持つ特定のオブジェクトを使用して、データベースのテーブル、列、および行を作成できます。

$column = new \Namespace\Data\Column ( /* name, type, null/non-null, etc... */ );
$myTable = new \Namespace\Data\Table( /* name, column objects, and indexes */ );

\Namespace\TableModel.create($myTable);

私の質問は...

他の誰かが、異なるレイヤー間の分離を提供するために何かを既に書いていますか?

そうでない場合、私のアプローチは長期的にはまったく役に立ちますか、それとも時間を無駄にしていますか。他のみんなと同じように、SQL を分解してハードコーディングする必要がありますか?

これを自分で書くのに役立つ場合、より効率的に処理するために私が取ることができるアプローチはありますか?

4

2 に答える 2

0

あなたはORMを探しているようです。これが1つです：http：//www.doctrine-project.org/docs/orm/2.0/en/tutorials/getting-started-xml-edition.html

于 2011-10-02T20:54:46.487 に答える
-1

正直に言うと、次の理由から、SQL をハードコードするだけです。

  1. 他のみんなもそうです。MySQL から別のものに変更したい場合は、WordPress の大部分を書き直す必要があります。システム全体の残りの部分がまだハードコーディングされた SQL でしか機能しない場合、プラグイン用に完璧なレイヤーを作成するのは時間の無駄です。

  2. 私たちは完璧な世界に住んでいません。抽象化が多すぎると、遅かれ早かれパフォーマンスやその他の問題が発生しますが、それについてはまだ考えていません。複雑にしないでおく。また、SQL を使用すると、パフォーマンスの「ハック」から恩恵を受けることができますが、これは他のシステムでは機能しない可能性があります。

  3. SQL は広く受け入れられている標準であり、すでに抽象化レイヤーとして認識されています。たとえば、SQL に似た構文 ( FQLを参照) を介して Facebook のグラフにアクセスすることさえ可能です。別のデータソースに変更したい場合は、とにかく SQL 構文をサポートするレイヤーが見つかるでしょう! その意味では、SQL はすでにある種の抽象化レイヤーであるとさえ言えます。

ただし: SQL を使用する場合は、必ず WordPress を使用して$wpdbください。これを使用すると、WordPress がデータベースへの接続やクエリの作成などを処理するため、安全な側にいます。ある日、WordPress がデータベースから別のものに変更することを決定した場合、彼らはデータベースを作成する必要があります。$wpdb-その新しいソースへのレイヤー - 後方互換性のため。また、多くの一般的な要求は既に$wpdb関数として ( など$wpdb->insert()) 含まれているため、SQL を直接ハードコーディングする必要はありません。

ただし、そのような抽象化レイヤーを使用することにした場合: ウィキペディアには詳細情報があります。

更新: CMS Drupal がデータベース抽象化レイヤーを使用していることがわかりましたが、すべての異なるデータベースに対して、SQL を使用してクエリを形成しています! これは、SQL がすでに抽象化レイヤーとしてどのように使用されているかを明確に示していると思います。

于 2011-10-02T21:06:28.357 に答える