3

OOP の原則は、何らかの理由で Web 開発に適用できなかったため、理解するのが困難でした。より多くのプロジェクトを開発するにつれて、コードの一部で特定のデザイン パターンを使用して、読みやすく、再利用し、維持しやすくする方法を理解し始めたので、ますます使用するようになりました。

私がまだ完全に理解できないことの 1 つは、なぜデータ層を抽象化する必要があるのか​​ということです。基本的に、DB に保存されているアイテムのリストをブラウザに出力する必要がある場合は、次のようにします。

$sql = 'SELECT * FROM table WHERE type = "type1"';'
$result = mysql_query($sql);

while($row = mysql_fetch_assoc($result))
{
    echo '<li>'.$row['name'].'</li>';
}

PDO の素晴らしさを説くハウツーや記事をすべて読んでいますが、その理由がわかりません。LoC を保存していないようです。また、上記で呼び出すすべての関数がクラスにカプセル化されているように見えますが、まったく同じことを行うため、どのように再利用できるかわかりません。私が PDO に見ている唯一の利点は、準備されたステートメントです。

データの抽象化が悪いと言っているわけではありません。現在のクラスを正しく設計しようとしていて、DB に接続する必要があるため、これらの質問をしています。これを正しい方法で行うと考えました。たぶん、私はこの件に関する悪い記事を読んでいるだけです:)

このテーマに関するアドバイス、リンク、または具体的な実際の例を本当に感謝します!

4

5 に答える 5

3

将来的に時間を節約する方法として、データ層を抽象化することを考えてください。

あなたの例を使用して。テーブルの名前を変更したとしましょう。そのテーブルを使用する SQL がある各ファイルに移動して編集する必要があります。最良の場合、N 個のファイルの検索と置換の問題でした。すべての SQL メソッドを含むファイルを 1 つだけ編集すれば、多くの時間を節約でき、エラーを最小限に抑えることができたはずです。

同じことが列名にも当てはまります。

これは、名前を変更する場合のみを考慮しています。データベース システムを完全に変更することも可能です。たとえば、SQL は Sqlite と MySQL の間で互換性がない可能性があります。繰り返しになりますが、多くのファイルを編集する必要があります。

抽象化により、ある部分を別の部分から切り離すことができます。この場合、ビュー パーツに影響を与えずにデータベース パーツに変更を加えることができます。

非常に小規模なプロジェクトの場合、これは必要以上に面倒なことになる可能性があります。それでも、少なくとも慣れるためには、それを行う必要があります。

于 2011-03-15T16:30:12.980 に答える
3

私はphpの人ではありませんが、これはより一般的な質問なので、ここに行きます.

あなたはおそらく小さなものを構築していますが、小規模/中規模のものでも、より良く成長できるように抽象化されたデータレイヤーが必要な場合があります。

CHANGEへの対応がポイント

これについて考えてみてください。あなたは小さなソーシャル ネットワーキング Web サイトを持っています。保存するデータ、プロフィールの詳細、写真、友達、メッセージについて考えてみましょう。これらのそれぞれについて、 のようなページがありますpictures.php?&uid=xxx。

次に、mysql コードを使用してそこに小さな SQL を平手打ちします。これを変更するのがどれほど簡単/難しいか考えてみてください。5〜10ページを変更しますか？これを行う場合、完全にテストする前に、おそらく数回間違えるでしょう。

ここで、Facebook について考えてみましょう。ページの量を考えてみてください。各ページで SQL の行を変更する方が簡単だと思いますか!?

データ アクセスを正しく抽象化すると、次のようになります。

  1. 1 か所にあるので、簡単に変更できます。
  2. したがって、テストが簡単です。
  3. 交換が簡単です。（別のデータベースに切り替える必要がある場合に何をしなければならないかを考えてください）

お役に立てれば

于 2011-03-15T16:30:37.333 に答える
2

データ層を抽象化することのもう 1 つの利点は、基盤となるデータベースへの依存度が低くなることです。

あなたの方法では、mysql 以外のものを使用したい日や、列の名前の変更、mysql の変更に関連する php API など、多くのコードを書き直す必要があります。

すべてのデータベース アクセス部分が適切に抽象化されていれば、必要な変更は最小限に抑えられ、プロジェクト全体ではなくいくつかのファイルに制限されます。

また、コードが 1 か所に集中していると、SQL インジェクションやその他のユーティリティ関数に関するコードを再利用するのがはるかに簡単になります。

最後に、プロジェクトのすべてのページではなく、一部のクラスを通過する方が単体テストを実行しやすくなります。

たとえば、私の最近のプロジェクト (申し訳ありませんが、コードの共有はできません) では、mysql 関連の関数は 1 つのクラスでのみ呼び出されます。クエリの生成からオブジェクトのインスタンス化まで、すべてここで行われます。したがって、別のデータベースに変更したり、このクラスを別の場所で再利用したりすることは、私にとって非常に重要です。

于 2011-03-15T16:30:52.870 に答える
1

私の意見では、データ アクセスは、コードの残りの部分から分離/抽象化する最も重要な側面の 1 つです。

さまざまな「レイヤー」を分離することには、いくつかの利点があります。

1) コードベースをきちんと整理します。変更が必要な場合は、変更が必要な場所とコードの場所がすぐにわかります。1 人でプロジェクトに取り組んでいる場合、これは大した問題ではないかもしれませんが、より大規模なチームの場合、そのメリットはすぐに明らかになります。この点は実際にはかなり些細なことですが、とにかく追加しました。本当の理由は2.

2) 変更が必要な可能性のあるものは、互いに独立して分離するようにしてください。特定の例では、ユーザー インターフェイスに影響を与えずに DB/データ アクセス ロジックを変更することが考えられます。または、データ アクセスに影響を与えずにユーザー インターフェイスを変更したい場合もあります。コードが互いに混ざり合っていると、これがどのように不可能になるかがわかります。

データ アクセス レイヤーに厳密に定義されたインターフェイスがある場合、その内部の仕組みを好きなように変更できます。また、インターフェイスに準拠している限り、それ以上の部分が壊れていないことを確信できます。明らかに、これにはまだテストによる検証が必要です。

3) 再利用する。データ アクセス コードの記述は、かなり繰り返しになる可能性があります。書き込むページごとにデータ アクセス コードを書き直す必要がある場合は、さらに反復的です。コード内で何かが繰り返されていることに気付いたときはいつでも、警報ベルが鳴っているはずです。反復性は、エラーが発生しやすく、メンテナンスの問題を引き起こします。

さまざまなページで同じクエリがポップアップ表示されるのをご存知でしょうか? これは、これらのクエリをデータ層の下位に配置することで解決できます。そうすることで、メンテナンスが容易になります。テーブルまたは列の名前が変更されるたびに、それを参照するデータ レイヤー内の 1 つの場所を修正するだけでよく、ユーザー インターフェイス全体を調べて何かを見落とす可能性はありません。

4) テスト。自動化されたツールを使用して単体テストを実行する場合は、すべてを適切に分離する必要があります。このコードがインターフェイス全体に散らばっている場合、すべての Customer レコードを選択するコードをどのようにテストしますか? データ アクセス オブジェクトに特定の SelectAllCustomers 関数があると、はるかに簡単になります。ここでこれを一度テストして、それを使用するすべてのページで機能することを確認してください。

他の人が追加できるようにする理由は他にもあります。取り除かなければならない主なことは、レイヤーを分離すると、変更が他のレイヤーに波及することなく、1 つのレイヤーを変更できることです。データベースとユーザー インターフェイスは、最も頻繁に変更されるアプリケーション/ウェブサイトの領域であるため、それらを分離し、他のすべてのものから適切に分離することをお勧めします。

于 2011-03-15T16:52:13.907 に答える
0

データベース テーブル内のアイテムのリストだけを印刷するという私の観点では、スニペットの方が適切です。高速、シンプル、明確です。

他のケースでは、関連するすべての利点を伴うコードの繰り返しを避けるために、もう少し抽象化することが役立つと思います。

著者、記事、タグ、および記事とタグの相互参照テーブルを備えた単純な CMS を考えてみましょう。

ホームページでは、単純なクエリがより複雑になります。記事とユーザーを結合し、各記事の関連タグを取得して、クロス リファレンス テーブルとタグ テーブルを結合し、article_id でフィルタリングします。

著者プロファイルとタグ検索結果にいくつかの小さな変更を加えて、このクエリを繰り返します。

このような抽象化ツールを使用すると、関係を一度定義して、次のようなより簡潔な構文を使用できます。

// Home page
$articles = $db->getTable('Article')->join('Author a')
    ->addSelect('a.name AS author_name');
$first_article_tags = $articles[0]->getRelated('Tag');

// Author profile
$articles = $db->getTable('Article')->join('Author a')
    ->addSelect('a.name AS author_name')->where('a.id = ?', $_GET['id']);

// Tag search results
$articles = $db->getTable('Article')->join('Author a')
    ->addSelect('a.name AS author_name')
    ->join('Tag')->where('Tag.slug = ?', $_GET['slug']);

モデルにカプセル化し、上記のコードをリファクタリングすることで、残りのコードの繰り返しを減らすことができます。

// Home page
$articles = Author::getArticles();
$first_article_tags = $articles[0]->getRelated('Tag');

// Author profile
$articles = Author::getArticles()->where('a.id = ?', $_GET['id']);

// Tag search results
$articles = Author::getArticles()
    ->join('Tag')->where('Tag.slug = ?', $_GET['slug']);

多かれ少なかれ抽象化する正当な理由は他にもあり、その長所と短所があります。しかし、私の意見では、Webプロジェクトの大部分は主にこれです:P

于 2011-03-16T00:06:45.127 に答える