39

私は実際に3層構造で立ち往生しています。インターネットをサーフィンしたところ、「データベース抽象化レイヤー」と「データ アクセス レイヤー」という 2 つの用語が見つかりました。

2つの違いは何ですか?

4

3 に答える 3

48

データ アクセス レイヤー = アプリケーション ドメインに固有の作成、読み取り、更新、削除 (CRUD) 操作

Data Abstraction Layer= は、接続、コマンド、パラメーターなどの一般的なデータベース操作を実行し、ベンダー固有のデータ ライブラリから隔離し、MySQL、Microsoft SQL Server、Oracle、DB2 などを使用しているかどうかに関係なく、データにアクセスするための 1 つの高レベル API を提供します...

于 2010-05-15T02:50:16.657 に答える
28

私の理解では、データ アクセス レイヤーは実際にはデータベースを抽象化するのではなく、データベースの操作とクエリの構築を容易にします。

たとえば、データ アクセス レイヤーには通常、SQL 構文に非常によく似た API がありますが、次のように記述するには、データベースの構造に関する知識が必要です。

$Users->select('name,email,datejoined')->where('rank > 0')->limit(10);

通常、データ抽象化レイヤーは本格的な ORM (オブジェクト リレーショナル マッパー) であり、理論的には基礎となるデータベース構造を理解したり、SQL の知識を持ったりする必要がありません。構文は次のようになります。

Factory::find('Users', 10)->filter('rank > 0');

また、すべてのオブジェクトにすべてのフィールドが完全に入力される可能性があり、そのように設定すると、親または子オブジェクトと結合される可能性があります。

ただし、この抽象化には代償が伴います。個人的には、ORM のようなドクトリンやプロペルは不必要で非効率的だと思います。ほとんどの場合、シンタックス シュガーのためにアプリケーションのパフォーマンスを破壊する代わりに、特別な注意が必要な場合は手動 SQL を使用して、単純なデータ アクセス レイヤーで問題ありません。この分野はかなり白熱した議論なので、これ以上立ち入りません。

データベース抽象化レイヤーを意味する場合、それは PDO に沿ったものであり、コードをより多くのデータベース ベンダーで使用できるようになります。PDO は MySQL、PostgreSQL、mysqli などで動作すると思います。

于 2010-05-15T02:50:47.710 に答える
11

ウィキから:

データ アクセス層

コンピュータ ソフトウェアのデータ アクセス レイヤ (DAL) は、エンティティ リレーショナル データベースなど、ある種の永続ストレージに格納されたデータへの簡単なアクセスを提供するコンピュータ プログラムのレイヤです。

たとえば、DAL は、データベース テーブルのフィールドの行ではなく、属性を備えたオブジェクトへの参照を (オブジェクト指向プログラミングの観点から) 返す場合があります。これにより、クライアント (またはユーザー) モジュールをより高いレベルの抽象化で作成できます。この種のモデルは、対応する一連のデータベース ストアド プロシージャを直接参照するデータ アクセス メソッドのクラスを作成することによって実装できます。別の実装では、ファイル システムとの間でレコードを取得または書き込む可能性があります。DAL は、基盤となるデータ ストアのこの複雑さを外界から隠します。

たとえば、insert、delete、update などのコマンドを使用してデータベース内の特定のテーブルにアクセスする代わりに、クラスといくつかのストアド プロシージャをデータベース内に作成できます。プロシージャはクラス内のメソッドから呼び出され、要求された値を含むオブジェクトが返されます。または、挿入、削除、および更新コマンドは、データ アクセス レイヤー内に格納された registeruser や loginuser などの単純な関数内で実行できます。

つまり、永続性/ストレージ層にプッシュ/プルするためのビジネス オブジェクトの基本的な CRUD機能/ロジックはここに当てはまります。ほとんどの場合、これだけが必要になる場合があります。ORM マッピング、モデルのビジネス オブジェクトのインターフェイスなどがここに該当します。

データベース抽象化レイヤー

データベース抽象化レイヤーは、コンピューター アプリケーションと SQL Server、DB2、MySQL、PostgreSQL、Oracle、SQLite などのデータベースとの間の通信を統合するアプリケーション プログラミング インターフェイスです。従来、すべてのデータベース ベンダーは自社製品に合わせた独自のインターフェイスを提供しており、アプリケーション プログラマーは、サポートしたいすべてのデータベース インターフェイスのコードを実装する必要があります。データベース抽象化レイヤーは、開発者に一貫した API を提供することで作業量を削減し、このインターフェイスの背後にあるデータベースの詳細を可能な限り隠します。多くのプログラミング言語には、さまざまなインターフェイスを持つ多くの抽象化レイヤーが存在します。

基本的に、これは抽象化の追加レイヤーであるため、ベンダーに依存しないインターフェイスに対してCRUDを実行し、さまざまなデータベース ベンダーの実装の詳細について心配する必要が少なくなります。これは、複数のデータベースをサポートする場合にのみ必要です。ORM、Micro ORM、ラッパー、ジェネリック ドライバー クラスなど、名前が何であれ、接続の確立、パラメーター処理、実行などを扱うものはここに分類されます。これは、Persistance/Storage レイヤーの直前の追加レイヤーです。3 層の用語では、これらの層は両方とも論理的に分離されていないため、1 つに分類されます。


要約すると、DAL はデータに関するものであり、DbAL はデータベースに関するものです。DAL は操作を定義し、DbAL は動作します。DAL は、実際の Db のすぐ後ろにある DbAL の後ろに位置します。DAL は DbAL を呼び出します。DAL はビジネス ロジック (モデル内) を CRUD ロジックから分離するのに適していますが、DbAL はほとんど必要ありません (しかし私は気に入っています)。DAL はより高レベルの設計マッピングであり、DbAL はより低レベルのアーキテクチャと実装です。どちらも責任を分離します。ORM は、その両方を実現する大規模な構造です。ORMを使用するときにそれらをどのように分離するかわかりません。ORM がすべてを処理してくれるので、その必要はありません。理想的には、とにかく、あるプロジェクトに DAL を配置し、別のプロジェクトに DbAL を配置します。これは、Db とその操作を分離する意味がないため、単に永続レイヤーと呼びます。

于 2013-01-19T12:14:25.520 に答える