なぜデータレイヤーを抽象化する必要があるのですか？

https://stackoverflow.com/questions/5314697

24-10-2019
|

質問

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の偉大さについて説教しているこれらすべてのハウツーや記事を読んでいますが、その理由はわかりません。私はロックを保存しているようには見えませんし、上記のすべての機能がクラスでカプセル化されているように見えるが、まったく同じことをするので、それがどのように再利用可能になるかはわかりません。私がPDOに見ている唯一の利点は、準備された声明です。

データの抽象化は悪いことだと言っているのではありません。現在のクラスを正しく設計しようとしているので、これらの質問をしています。右仕方。たぶん私はこの主題に関する悪い記事を読んでいるだけです:)

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

解決

データレイヤーを抽象化する他の利点の1つは、基礎となるデータベースへの依存度が低くなることです。

メソッド、MySQL以外の何かを使用したい日、または列の名前付けの変更、またはMySQLの変更に関するPHP APIを使用すると、多くのコードを書き直す必要があります。

すべてのデータベースアクセスパーツがきちんと抽象化されている場合、必要な変更は最小限になり、プロジェクト全体ではなくいくつかのファイルに制限されます。

また、コードが1か所に集中している場合、SQLインジェクションまたはその他のユーティリティ機能に関するコードを再利用する方がはるかに簡単です。

最後に、プロジェクトのすべてのページよりもすべてがいくつかのクラスに侵入した場合、ユニットテストを行う方が簡単です。

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

他のヒント

データレイヤーを抽象化することは、将来の時間を節約する方法として考えてください。

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

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

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

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

非常に小さなプロジェクトでは、これは価値があるよりもトラブルかもしれません。そして、それでも、少なくとも慣れるには、まだそれをする必要があります。

私はPHPの人ではありませんが、これはより一般的な質問ですので、ここにあります。

あなたはおそらく小さなものを構築しますが、時には小さな/媒体でさえ抽象化されたデータレイヤーがあるはずです。

ポイントは対処することです 変化する

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

その後、MySQLコードでSQLの小さな断片がそこに平手打ちされます。今、これを変えるのがどれほど簡単/難しいかを考えますか？ 5〜10ページを変更しますか？これを行うと、徹底的にテストする前に、おそらく数回間違っているでしょう。

さて、Facebookを考えてください。そこにあるページの量を考えてください、あなたはそれがより簡単になると思いますか 変化する 各ページのSQLの行！？

データアクセスを正しく抽象化すると：

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

お役に立てれば

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

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

1）コードベースをきちんと整理します。変更を行う必要がある場合は、変更を行う必要がある場所とコードを見つける場所がすぐにわかります。自分でプロジェクトに取り組んでいる場合、これはそれほど大したことではないかもしれませんが、より大きなチームでは、すぐに利益が明らかになる可能性があります。この点は実際にはかなり些細なことですが、とにかく追加しました。本当の理由は2番です。

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

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

3）再利用。データアクセスコードを作成すると、かなり反復的になります。書いたページごとにデータアクセスコードを書き換える必要がある場合、さらに反復的です。コードで繰り返し何かに気付くときはいつでも、アラームベルが鳴っているはずです。繰り返しは、エラーを起こしやすく、メンテナンスの問題を引き起こします。

同じクエリがさまざまな異なるページにポップアップ表示されていると思いますか？これは、これらのクエリをデータレイヤーの下に下げて解決できます。そうすることは、メンテナンスを容易にするのに役立ちます。テーブルまたは列名が変更されるたびに、ユーザーインターフェイス全体をトロールする代わりに、それを参照するデータレイヤーの1つの場所を修正するだけで、潜在的に何かが欠けています。

4）テスト。自動化されたツールを使用してユニットテストを実行する場合は、すべてがうまく分離されている必要があります。このコードがインターフェイス全体に散らばっている場合、すべての顧客レコードを選択するためにコードをテストしますか？データアクセスオブジェクトに特定のselectalcustomers関数を持っている場合、はるかに簡単です。ここで一度テストし、使用するすべてのページで機能することを確認できます。

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

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

おもう少し他のケースでは、関連するすべての利点があるコードの繰り返しを避けるために、より多くの抽象化が役立つ可能性があります。

著者、記事、タグ、記事やタグのクロスリファレンステーブルを備えた簡単なCMSを検討してください。

ホームページでは、簡単なクエリがより複雑になります。記事とユーザーに参加してから、クロスリファレンスワンでタグテーブルに参加し、記事_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

ライセンス： CC-BY-SA と帰属

所属していません StackOverflow