データベース抽象化レイヤーとデータアクセスレイヤーの違いは何ですか？
私は実際には3層構造で立ち往生しています。インターネットをサーフィンして、「データベース抽象化レイヤー」と「データアクセスレイヤー」という2つの用語を見つけました。
2つの違いは何ですか？
私の理解では、データアクセス層は実際にはデータベースを抽象化するのではなく、データベース操作とクエリの構築を容易にします。
たとえば、データアクセス層には通常、SQL構文に非常によく似たAPIがあり、次のように記述するためにデータベースの構造に関する知識が必要です。
$Users->select('name,email,datejoined')->where('rank > 0')->limit(10);
データ抽象化レイヤーは通常、本格的なORM（Object-Relational Mappers）であり、基礎となるデータベース構造を理解したり、SQLの知識を持ったりする必要を理論的に防ぎます。構文は次のようになります。
Factory::find('Users', 10)->filter('rank > 0');
また、すべてのオブジェクトにすべてのフィールドが完全に入力されている可能性があり、そのように設定すると、親オブジェクトまたは子オブジェクトと結合される可能性があります。
ただし、この抽象化には代償が伴います。個人的には、ORMのようなdoctrineまたは推進力は不要で非効率的だと思います。ほとんどの場合、単純なデータアクセス層で問題なく動作し、特別な注意が必要なものはすべて手動SQLで破棄する必要はありません。いくつかのシンタックスシュガーに対するアプリケーションのパフォーマンス。この領域はかなり白熱した議論なので、これ以上は説明しません。
データbase抽象化レイヤーを意味する場合、それはPDOに沿ったものになるため、コードをより多くのデータベースベンダーで使用できます。 PDOは、MySQL、PostgreSQL、mysqliなどで動作すると思います。
ウィキから：
コンピュータソフトウェアのデータアクセス層（DAL）は、エンティティリレーショナルデータベースなど、ある種の永続ストレージに格納されているデータへの簡略化されたアクセスを提供するコンピュータプログラムの層です。
たとえば、DALは、データベーステーブルのフィールドの行ではなく、属性を備えたオブジェクトへの参照を（オブジェクト指向プログラミングの観点から）返す場合があります。これにより、クライアント（またはユーザー）モジュールをより高いレベルの抽象化で作成できます。この種のモデルは、対応するデータベースストアドプロシージャのセットを直接参照するデータアクセスメソッドのクラスを作成することで実装できます。別の実装では、ファイルシステムとの間でレコードを取得または書き込む可能性があります。 DALは、基盤となるデータストアのこの複雑さを外部から隠します。
たとえば、挿入、削除、更新などのコマンドを使用してデータベース内の特定のテーブルにアクセスする代わりに、クラスといくつかのストアドプロシージャをデータベースに作成できます。プロシージャはクラス内のメソッドから呼び出され、要求された値を含むオブジェクトを返します。または、挿入、削除、更新コマンドは、データアクセス層内に格納されているregisteruserやloginuserなどの単純な関数内で実行できます。
つまり、永続性/ストレージレイヤーにプッシュ/プルするビジネスオブジェクトの基本的なCRUD機能/ロジックはここにあります。ほとんどの場合、これだけが必要になる場合があります。 ORMマッピング、モデルのビジネスオブジェクトのインターフェイスなどはここにあります。
データベース抽象化レイヤーは、コンピューターアプリケーションとSQL Server、DB2、MySQL、PostgreSQL、Oracle、SQLiteなどのデータベースとの間の通信を統合するアプリケーションプログラミングインターフェイスです。従来、すべてのデータベースベンダーは、自社の製品に合わせた独自のインターフェイスを提供しており、アプリケーションプログラマは、サポートしたいすべてのデータベースインターフェイスのコードを実装する必要があります。データベース抽象化レイヤーは、開発者に一貫したAPIを提供することで作業量を削減し、データベースの詳細をこのインターフェイスの背後に可能な限り隠します。多くのプログラミング言語には、異なるインターフェースを持つ多くの抽象化レイヤーが存在します。
基本的に、その追加の抽象化レイヤーにより、ベンダーに依存しないインターフェイスに対して[〜＃〜] crud [〜＃〜]し、さまざまなデータベースベンダーの実装の詳細について心配する必要がなくなります。これが必要になるのは、複数のデータベースをサポートする場合のみです。 ORM、マイクロORM、ラッパー、汎用ドライバークラス、名前が何であれ、接続の確立、パラメーターの処理、実行などを処理するがここに含まれます。これは、永続性/ストレージレイヤーの直前の追加レイヤーです。 3層の用語では、これらの層は論理的に分離されていないため、両方とも1つに分類されます。
要約すると、DALはデータに関するものであり、DbALはデータベースに関するものです。 DALは操作を定義し、DbALは操作します。 DALは、実際のDbのすぐ後ろにあるDbALの後ろにあります。 DALはDbALを呼び出します。 DALは（モデル内の）ビジネスロジックをCRUDロジックから分離するのに適していますが、DbALはめったに必要ありません（しかし私はそれが大好きです）。 DALはより高レベルの設計マッピングであり、DbALはより低レベルのアーキテクチャと実装です。どちらも責任を分離します。 ORMは、両方を行う大規模な構造です。 ORMを使用するときにそれらをどのように分離するかはわかりません。 ORMがすべてを処理するので、必要はありません。理想的には、とにかく1つのプロジェクトにDALがあり、別のプロジェクトにDbALがあり、Dbとその操作を分離する意味がないため、単に永続層と呼びます。