私はずっと前にプロジェクトを開始し、ソリューションでデータ アクセス レイヤープロジェクトを作成しましたが、その中で何も開発したことがありません。データ アクセス層の目的は何ですか? データ アクセス レイヤーについて詳しく学べる良い情報源はありますか?
10 に答える
2 つの言葉で:疎結合
データ ストア (データベース、フラット ファイル、Web サービスなど) からデータを取得するために使用するコードを、ビジネス ロジックやプレゼンテーション コードから分離しておくため。これにより、データ ストアを変更する必要がある場合でも、すべてを書き直す必要がなくなります。
最近では、さまざまな ORM フレームワークが DAL を他のレイヤーとブレンドしています。通常、これにより開発が容易になりますが、データ ストアの変更は面倒な場合があります。公平を期すために、そのようなデータ ストアの変更は非常にまれです。
データ アクセス層の主な目的は 2 つあります。
実際のデータベース エンジンまたはその他のデータ ストアを抽象化して、アプリケーションがたとえば Oracle の使用から MS SQL サーバーの使用に切り替えることができるようにします。
ビジネスレイヤーがこの知識から切り離され、それにとらわれないように、論理データモデルを抽象化します。ビジネス層に影響を与えずに論理データ モデルを変更できるようにする
ここでのほとんどの回答は、最初の理由を提供しています。私の考えでは、はるかに重要なのは2番目です。基本的に、ビジネス レイヤーは、使用中の論理データ モデルを認識する必要はありません。今日、ORM と Linq を使用すると、#2 は窓の外に出てしまい、人々は #2 について忘れがちです (または、存在し、存在するはずの細かい線を見ることができません)。
基本的に、データ レイヤーの目的と機能を十分に理解するには、ビジネス レイヤーの観点から物事を見る必要があります。ビジネス レイヤーはデータ ストアの論理データ モデルに依存しない必要があることに注意してください。
したがって、ビジネス層がデータを必要とするたびに、たとえば、非常に単純な論理データ モデルにとらわれない方法で必要なデータを要求する必要があります。そのため、次のようなデータ アクセス レイヤーへの呼び出しが行われます。
GetOrdersForCustomer(42)
そして、どのテーブルにこの情報が格納されているか、関係が存在するかなどを意識することなく、必要なデータを正確に取得します。
詳しく書いた記事をブログに書いています。
データ アクセス レイヤーは、ビジネス ロジックがデータ レイヤー (データベース) と対話するために必要なすべてのロジックが単一のクラス セット (レイヤー) に分離される「関心の分離」の考え方に従います。これにより、バックエンドの物理データ ストレージ テクノロジをより簡単に変更できます (たとえば、XML ファイルからデータベースへの移行、または SQL Server から Oracle または MySQL への移行など)。ビジネスの論理。
データレイヤーの構築に役立つツールはたくさんあります。「オブジェクト リレーショナル マッパー」または「ORM」という語句を検索すると、より詳細な情報が見つかるはずです。
アプリケーションの多くの異なる部分が同じ方法でデータにアクセスする必要がある場合、データ アクセス レイヤーは非常に理にかなっています。
また、同じデータにさまざまな方法でアクセスする必要がある場合にも意味があります。たとえば、ワード プロセッサがさまざまな種類のファイルを読み取って、アプリケーションの内部形式に静かに変換する方法などです。
DAL は非常に逆効果になる可能性があることに注意してください。データ アクセスのパフォーマンスが重要なシステムを構築している場合、システムをビジネス ロジックから分離すると、いくつかの重要な最適化が不可能になる可能性があります。
DAL はプロジェクトの残りの部分からデータベースを抽象化する必要があります。基本的に、DAL 以外のコードには SQL が含まれていてはならず、DAL だけがデータベースの構造を認識している必要があります。
主な目的は、アプリケーションの残りの部分をデータベースの変更から隔離し、アプリケーションの拡張とサポートを容易にすることです。これは、データベース インタラクション コードを変更する場所が常にわかっているためです。
目的は、アプリケーションの他の部分が気にする必要のないデータベース アクセスの詳細を抽象化することです。
データ アクセス レイヤーは、データの格納と取得をその表現から抽象化するために使用されます。この種の抽象化については、1994 年のデザイン パターンで詳しく読むことができます。
目的は、データの使用と操作からデータ ストレージの取得メカニズムを抽象化することです。
利点:
- 基盤となるストレージは変更される可能性があり (たとえば、Oracle から MSSQL への切り替え)、それらの変更をローカライズする方法が必要です。
- スキーマの変更 - 上記を参照
- データベースから切断して実行する方法が必要です (デモモード): ファイルのシリアル化/逆シリアル化を DAL に追加します。
ここを読むことをお勧めします: http://msdn.microsoft.com/en-us/practices/default.aspx DAL を使用すると、プレゼンテーションやビジネス ロジックからデータ アクセスを分離するのに役立ちます。(リフレクションと動的なアセンブリの読み込みを通じて) データ プロバイダーを簡単に交換できるように、私はこれを頻繁に使用しています。
読んでください、そこにはたくさんの良い情報があります。
また、.NET の使用を計画している場合は、データ アクセス ブロックを調べてください。それは大きな助けになることができます。