1 つは低レベルの呼び出しをデータに依存しないフレームワーク (例: ExecuteCommand メソッドなど) に抽象化し、もう 1 つは通常ビジネス固有のメソッド (例: UpdateCustomer) を含むことを読んだことを覚えています。
これは正しいです?どれがどれですか?
1 つは低レベルの呼び出しをデータに依存しないフレームワーク (例: ExecuteCommand メソッドなど) に抽象化し、もう 1 つは通常ビジネス固有のメソッド (例: UpdateCustomer) を含むことを読んだことを覚えています。
これは正しいです?どれがどれですか?
私にとって、これはプロジェクトの設計をどのように処理したいかについての個人的な設計上の決定です。データ アクセスとデータ サービスが同じである場合があります。.NET と LINQ の場合はそうです。
私にとって、データ サービス層は実際にデータベースへの呼び出しを行うものです。データ アクセス レイヤーはオブジェクトを受け取り、データ サービス レイヤーがデータベースを呼び出すようにオブジェクトを作成または変更します。
私の設計では、ビジネス ロジック レイヤーがビジネス ルールに基づいてオブジェクトを操作し、それらをデータ アクセス レイヤーに渡します。データ アクセス レイヤーは、データベースまたはデータベースからのオブジェクトに入るようにフォーマットします。データ サービス レイヤーは、実際のデータベース呼び出しを処理します。 .
一般に、この 2 つの用語は互換性があると思いますが、開発環境のコンテキストによっては、より具体的な意味を持つ場合があります。
データ アクセス層は、データとアプリケーションの境界にあります。「データ」とは、アプリケーションが使用するさまざまなデータ ソースのセットです。これは、複数のソースからデータを収集するために、各アプリケーションでかなりのコーディングを行う必要があることを意味します。必要なデータ ビューを作成するコードは、一部のアプリケーションで冗長になります。
データ ソースの数が増え、より複雑になるにつれて、データ アクセス、変換、および統合の詳細に対処するために、データ アクセスのさまざまなタスクを分離することが必要になります。適切に設計されたデータ サービスを使用すると、ビジネス サービスはより高いレベルの抽象化でデータとやり取りできるようになります。データ アクセス、統合、セマンティック解決、変換、および再構築を処理して、アプリケーションが必要とするデータ ビューと構造に対処するデータ ロジックは、データ サービス レイヤーにカプセル化するのが最適です。
データ サービス層をさらにその構成要素 (つまり、データ アクセス、変換、および統合) に分割することができます。このような場合、データの取得のみに関係する「データ アクセス レイヤー」と、データ アクセス レイヤーを介してデータを取得し、取得したデータを組み合わせて、必要なさまざまなオブジェクトに変換する「データ サービス レイヤー」が存在する可能性があります。ビジネス サービス層。
WebSphere Commerceの資料で行われているデータ・サービス層の概念は単純です。
データ サービス層 (DSL) は、物理スキーマから独立したデータ アクセス用の抽象化層を提供します。データ サービス層の目的は、オブジェクト リレーショナル マッピング フレームワークとは無関係に、データにアクセスするための一貫したインターフェイス (データ サービス ファサードと呼ばれる) を提供することです。
現在、インターネットでは、DSLの概念は主にSOA (サービス指向アーキテクチャ)に関連付けられていますが、それだけではありません。これは、N 層アプリケーションの例で言及されています。